stringtranslate.com

Ayuda para hablar:Estilo de cita 1

¿Qué tal si las URL de PubMed fueran más cortas?

¿Los bots que están limpiando CS1 deberían reemplazar URL como https://pubmed.ncbi.nlm.nih.gov/18566177/ por URL como https://pubmed.gov/18566177? Creo que sí. (Es molesto que las URL como https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4345631 no se puedan acortar a https://pubmed.gov/PMC4345631 porque no redireccionan a la ubicación correcta. Sin embargo, se puede eliminar "/articles").

En otras palabras, propongo que https://pubmed.ncbi.nlm.nih.gov/<PMID>[/] se reemplace por https://pubmed.gov/<PMID> cuando los bots estén realizando otras tareas de limpieza de CS1 (mismas reglas). RememberOrwell ( discusión ) 10:34 17 sep 2024 (UTC) [ responder ]

En realidad, estas URL deberían eliminarse por completo. Hacen que parezca que hay una versión gratuita completa cuando no la hay. Sin embargo, no tengo una opinión sobre acortar la URL que se usa en la plantilla o los identificadores. Headbomb { t · c · p · b } 10:53, 17 de septiembre de 2024 (UTC) [ responder ]
Siempre debes usar el enlace directo y no una redirección, incluso si esa redirección es más ordenada. A medida que los sitios web cambian con el tiempo, las redirecciones suelen ser lo primero que se elimina o se pierde. Es probable que Pubmed sea más estable que la mayoría, pero aún así aplicaría la regla general. -- LCU A ctively D isinterested « @ » ° ∆t ° 10:56, 17 de septiembre de 2024 (UTC) [ responder ]
Si una cita CS1 contiene una URL completa válida para un PMID, se debe convertir para usarla |PMID=. De esa manera, si la URL cambia, los módulos CS1 se pueden arreglar y todas las citas seguirán funcionando. – Jonesey95 ( discusión ) 11:14, 17 de septiembre de 2024 (UTC) [ responder ]
En la práctica, los sitios web no siempre cambian todas las URL por igual. Cambian algunas, eliminan otras, mantienen otras. El método de arriba hacia abajo es la forma en que se introduce la degradación silenciosa de enlaces. -- Green C 23:22, 17 de septiembre de 2024 (UTC) [ responder ]
Gracias @ Michael Bednarek por la restauración.
PubMed.gov es un dominio dedicado creado para este propósito, lo que sugiere estabilidad. A menudo, una página de PubMed enlaza a una copia gratuita sin un PMCID. Me pregunto si alguien ha realizado algún ajuste de visualización para mostrar los enlaces de sci-hub. (No estoy diciendo que el sitio principal debería ofrecerlos de forma predeterminada, eso sería un fracaso, incluso para un sitio web de contenido gratuito. Presencia corporativa importante...) RememberOrwell ( discusión ) 14:26, 18 de septiembre de 2024 (UTC) [ responder ]

Copias gratuitas tangente

Los enlaces de PMID nunca enlazan a copias gratuitas. Cuando hay una copia gratuita, se enlaza a través de PMCID . Los bots se encargan de eso. Headbomb { t · c · p · b } 15:11, 18 de septiembre de 2024 (UTC) [ responder ]
¿De qué estás hablando, @ Headbomb ? Con frecuencia eso no es cierto; ejemplo aquí con dos enlaces bajo "enlaces de texto completo". Falso: ejemplo en el OP anterior: #Deberíamos agregar soporte para el acceso a archivos. Falso: ejemplo en el OP anterior: #Deberíamos agregar soporte para el acceso a archivos. RememberOrwell ( discusión ) 05:24, 25 de septiembre de 2024 (UTC) [ responder ]
En ambos casos, se trata del enlace DOI, que el robot de citas puede marcar automáticamente como de lectura libre con |doi-access=free, y el enlace PMCID, que la plantilla marcará automáticamente como de lectura libre cuando se utilice el |pmc=parámetro. Si se coloca la URL pmid, se suprimirán estos enlaces de lectura libre en favor del enlace PMID de solo resumen. Ver
PMID en la URL: enlaces solo al resumen
  • Asim, A.; Kumar, A.; Muthuswamy, S.; Jain, S.; Agarwal, S. (2015). ""Síndrome de Down: una mirada a la enfermedad"". Revista de Ciencias Biomédicas . 22 (1): 41. doi : 10.1186/s12929-015-0138-y . PMC  4464633 . PMID  26062604.
No se especificó ninguna URL: se vincula automáticamente a la versión completa de PMC
  • Asim, A.; Kumar, A.; Muthuswamy, S.; Jain, S.; Agarwal, S. (2015). ""Síndrome de Down: una mirada a la enfermedad"". Revista de Ciencias Biomédicas . 22 (1): 41. doi : 10.1186/s12929-015-0138-y . PMC  4464633 . PMID  26062604.
Headbomb { t · c · p · b } 05:34, 25 de septiembre de 2024 (UTC) [ responder ]
Vale, pero hay mejores ejemplos, y lo que he dicho es cierto: 1. PubMed.gov es un dominio dedicado creado para este fin, lo que sugiere estabilidad. 2. A menudo, una página de PubMed enlaza a una copia gratuita sin una versión de PMC. 3. El ejemplo del OP anterior: #Deberíamos añadir compatibilidad con el acceso a archivos refuta dos afirmaciones anteriores. CS1 podría ser más útil en https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1/Cardiac_stress_test#cite_note-13, pero estoy de acuerdo en que podría ser contraproducente hacerlo así, por la razón de GreenC. I'mRememberOrwell ( discusión ) 05:54, 25 de septiembre de 2024 (UTC) [ responder ]
"A menudo, una página de PubMed contiene un enlace a una copia gratuita sin una versión de PMC"
En ese caso, se puede vincular a través de |doi-access=, o un enlace a la versión gratuita real. En el caso de PMID  28799256, es https://hal.science/hal-01688786. Headbomb { t · c · p · b } 07:53, 25 de septiembre de 2024 (UTC) [ responder ]
Lo cual no tiene nada que ver con URL de PubMed más cortas, ¿verdad? Desglosado. RememberOrwell ( discusión ) 06:37, 27 de septiembre de 2024 (UTC) [ responder ]
El punto es que cualquier robot que "acorte" estas URL debería eliminarlas para que no ocupen el lugar de los enlaces gratuitos. Headbomb { t · c · p · b } 06:53, 27 de septiembre de 2024 (UTC) [ responder ]

Advertencia falsa cuando la URL es 'usurpada'

Hola a todos. No es un gran problema, pero vale la pena analizarlo. Noté que Module:Citation/CS1 muestra un mensaje de mantenimiento cuando una referencia está etiquetada con | url-status=usurped. Un ejemplo es ICD-11 , ref 62.

Los mensajes de mantenimiento no son lo mismo que los errores. Los primeros son verdes , los segundos son rojos . Los mensajes de mantenimiento normalmente no son visibles, a menos que los hagas visibles, como hice en mi common.css .

Cuando obtengo una vista previa de una página con una usurpedfuente etiquetada, se muestra esta advertencia en la parte superior:

"Advertencia de script: Una o más (...) plantillas tienen mensajes de mantenimiento ; los mensajes pueden estar ocultos ( ayuda )."

Además, en mi caso, las usurpedreferencias etiquetadas con - tienen este bit etiquetado al final:

" Mantenimiento CS1: URL no apta ( enlace )"

El bot GreenC ha estado marcando (correctamente) miles de URL como usurpedparte de un esfuerzo por combatir el spam pasivo de un sindicato de apuestas de Indonesia que ataca a Wikipedia; consulte Wikipedia:Abuso a largo plazo/Judi para obtener más información. Esta organización sospechosa vuelve a registrar nombres de dominio vencidos y los convierte en sitios de spam.

Los mensajes de mantenimiento deben ser un error en Module:Citation/CS1 , porque no veo ninguna razón por la que el script deba arrojar una advertencia de "URL no apta" cuando una referencia está marcada correctamente como usurped. Nuevamente, esto no es un gran problema, porque los mensajes de mantenimiento generalmente no se pueden ver. Pero sigue siendo un error, por lo que debe solucionarse algún día. Saludos, Manifestation ( discusión ) 19:40, 25 de septiembre de 2024 (UTC) [ responder ]

@ Manifestación Eso no es un problema y no es una advertencia. Es exactamente el trabajo de esa categoría de seguimiento. Lee la introducción en Category:CS1 maint: unfit URL :

Esta categoría de seguimiento oculta enumera páginas con citas CS1 que utilizan |url-status=usurpedo |url-status=unfit.

Las palabras clave unfity usurpedtienen como objetivo identificar URL originales que apuntan a sitios activos que son inapropiados: spam, publicidad, pornografía, etc.

Una URL que devuelve un error HTTP 404 no se considera no apta y, en tales casos, los editores deben establecer |url-status=dead.

Las plantillas CS1 y CS2 en las páginas enumeradas en esta categoría deben revisarse para garantizar que las palabras clave unfity usurpedse apliquen correctamente.

Sólo el Módulo:Cita/CS1 debe agregar páginas directamente a esta categoría.

Las páginas con esta condición se colocan automáticamente en Categoría:CS1 mantenimiento: URL no apta.

Algunas categorías de seguimiento ocultas son solo eso: categorías que rastrean aplicaciones válidas de ciertas plantillas en determinadas condiciones. FeRDNYC ( discusión ) 17:46 26 sep 2024 (UTC) [ responder ]
(No sé de dónde viene el mensaje de "Advertencia de script", parece que es algún script de usuario que hayas instalado. No lo veo, solo veo el mensaje de mantenimiento de CS1 adjunto a la cita en la lista de referencias. Pero el mensaje en sí no es una advertencia; algún script te está advirtiendo de la existencia del mensaje). FeRDNYC ( discusión ) 17:49 26 sep 2024 (UTC) [ responder ]
La advertencia de script es una característica de MediaWiki. Módulo:Cita/CS1 coloca mensajes sobre errores y problemas de mantenimiento en el cuadro amarillento en la parte superior de una página vista previa. MediaWiki antepone el texto 'Advertencia de script:' a cada mensaje de cs1|2. Vea un ejemplo en Ayuda:Errores de CS1 § Controlar la visualización de mensajes de error .
—El monje trapense ( discusión ) 18:18 26 sep 2024 (UTC) [ responder ]
Eh, gracias. Me pregunto por qué no lo veo. ¿Se muestra incluso cuando se usa la interfaz de edición del Editor visual (en modo de origen)? ... Podría ser que el userCSS que instalé para mostrar los mensajes ocultos también oculte ese mensaje, tendré que comprobarlo. FeRDNYC ( discusión ) 18:24, 26 de septiembre de 2024 (UTC) [ responder ]
No tengo ni idea de nada que tenga que ver con ve; no me acercaré a esa cosa. Sin duda hay personas que sí usan ve y que podrían responder a tu pregunta. Parece un fallo de diseño si un sistema de mensajería de MediaWiki no funciona con ve de MediaWiki.
—El monje trapense ( discusión ) 19:04 26 sep 2024 (UTC) [ responder ]
(En una nota no relacionada, ese artículo de la CIE-11 está plagado de enlaces externos (a https://icd.who.int/), que normalmente no están permitidos en los cuerpos de los artículos. ¿Se decidió algún tipo de excepción para esos enlaces, o es necesario convertirlos en citas?) FeRDNYC ( discusión ) 17:56, 26 de septiembre de 2024 (UTC) [ responder ]
(Para responder a mi propia pregunta, todos esos enlaces externos se crean utilizando y , por lo que supongo que son excepciones). FeRDNYC ( discusión ) 18:26 26 sep 2024 (UTC) [ responder ]{{ICD10}}{{ICD11}}
@FeRDNYC :
" No es una advertencia " . El mensaje de
vista previa dice que lo es .
" Es exactamente el trabajo de esa categoría de seguimiento " .
Eso está bien. El seguimiento no es el problema. El seguimiento es bueno. El problema es el mensaje de mantenimiento. Estos mensajes implican que algo necesita mantenimiento, es decir, reparación, es decir, limpieza. Pero no hay nada que mantener/reparar/limpiar aquí. La advertencia del script es injusta.
" No sé de dónde viene el mensaje de "Advertencia de script", parece que es un script de usuario que haya instalado " .
Proviene del software MediaWiki. No tengo scripts instalados (locales ni globales).
@El monje trapense:
Eso es correcto.
- Manifestación ( discusión ) 18:30 26 septiembre 2024 (UTC) [ responder ]
Las plantillas cs1|2 no pueden anular el texto proporcionado por MediaWiki, por lo que estamos atascados con 'Advertencia de script'.
—El monje trapense ( discusión ) 19:04 26 sep 2024 (UTC) [ responder ]
Estos mensajes implican que algo necesita mantenimiento, es decir, reparación, limpieza. Pero no hay nada que mantener/reparar/limpiar aquí. La advertencia del script es injusta. Bueno, en cuanto a tu último punto, estoy de acuerdo; no hay razón para estar "advirtiendo" al usuario per se . Pero como dice el monje @Trappist, estamos atascados con el texto de "Advertencia del script", y la "advertencia" es simplemente que hay mensajes de mantenimiento, de cualquier forma, para cualquier cita en la página.
En cuanto al mensaje de mantenimiento en sí, el texto de introducción de la categoría proporciona el "llamado a la acción" que explica por qué se muestran y rastrean esos mensajes: las plantillas CS1 y CS2 en las páginas incluidas en esta categoría deben verificarse para garantizar que las palabras clave y se apliquen correctamente. Es cierto que esto es un poco engañoso, ya que todavía no hay forma de eliminar una página de la categoría una vez que se HA "verificado para garantizar...".unfitusurped
Supongo que se puede argumentar que |url-status=usurped/ |url-status=unfitson (se espera que sean) parámetros que se usan con poca frecuencia y que justifican "vigilarlos" indefinidamente. Pero, como dije, entiendo tu punto de vista de que la limpieza de esa categoría no es posible, algo que, según tengo entendido, la hace única entre las subcategorías de mantenimiento de Category:CS1 .
Hay un tercer tipo de seguimiento para las plantillas de citas más allá de los errores y el mantenimiento: Category:CS1 properties . En su mayoría contiene subcategorías que no generan mensajes visibles y no están pensadas para la limpieza; tal vez sería mejor hacer un seguimiento de "unfit url" con una propiedad en lugar de un mensaje de mantenimiento, @Trappist. (De hecho, Category:CS1 properties incluso contiene Category:CS1: abbreviated year range , un conjunto de inclusiones que parecen tener potencial de limpieza, más que unfit-url, de todos modos. Por lo tanto, parece una especie de inversión tener year-range-abbreviated en properties pero unfit-url en mantenimiento). FeRDNYC ( discusión ) 01:29, 27 de septiembre de 2024 (UTC) [ responder ]
FeRDNYC , la existencia de una plantilla de enlaces externos ampliamente transcluida no significa necesariamente que siempre sea bueno ponerla en el texto principal (la mayoría de las transclusiones de {{ ICD10 }} , por ejemplo, parecen estar en los cuadros de navegación). Sin embargo, en este caso (dado que este es el artículo sobre la obra de referencia a la que apunta la plantilla, y hay como trescientos enlaces externos que generalmente llevan a un enlace interno), no estoy realmente convencido de que ponerlos en citas o eliminarlos beneficie a alguien, independientemente de las siglas MOS que contravengan. Folly Mox ( discusión ) 01:53, 27 de septiembre de 2024 (UTC) [ responder ]
Es cierto y es un punto excelente. De hecho, la documentación de esas plantillas dice que están "pensadas principalmente para usarse con " (una plantilla de formato de enlaces externos). FeRDNYC ( discusión ) 03:03 27 sep 2024 (UTC) [ responder ]{{medical resources}}
Entonces... ¿esto se va a arreglar?
Me gusta la idea de User:FeRDNYC de convertir esto en una propiedad CS1 . Supongo que sería Category:CS1 con una URL marcada como usurpada y Category:CS1 con una URL marcada como no apta. ¿Hay alguien que pueda implementar esto? Saludos, Manifestation ( discusión ) 18:11 2 oct 2024 (UTC) [ responder ]
Llegué tarde a esta conversación, pero ¿estás buscando Category:CS1 maint: unfit URL ? ¿O estás sugiriendo que la categoría de mantenimiento debería estar en las propiedades Category:CS1 ? – Jonesey95 ( discusión ) 00:53, 3 octubre 2024 (UTC) [ responder ]
Por favor, lea la conversación completa. MediaWiki da una advertencia de mantenimiento falsa cuando una referencia está marcada con | url-status=usurped. Que tenga un buen día, Manifestación ( discusión ) 13:36, 4 de octubre de 2024 (UTC) [ responder ]

Nueva categoría de linter para identificaciones duplicadas

En caso de que quieras arreglar algo, hay una nueva categoría de linter para identificadores HTML duplicados. Es Special:LintErrors/duplicate-ids . (Puede que se agote el tiempo de espera, aquí está la versión solo para el espacio principal: [1]). Les informo a las personas de esta página porque muchos de ellos se deben a identificadores CITEREF duplicados. Izno ( discusión ) 20:45, 26 de septiembre de 2024 (UTC) [ responder ]

¿No es de esperar que haya referencias CITEREF duplicadas? Los artículos que utilizan referencias en línea podrían utilizar fuentes diferentes que tienen el mismo autor y año, y el software wiki ya se ocupa de esto automáticamente. -- LCU A ctively D isinterested « @ » ° ∆t ° 21:31, 26 de septiembre de 2024 (UTC) [ responder ]
Sí. Sigue siendo malo emitir identificadores duplicados: anteriormente, el software solo eliminaba los identificadores duplicados, pero es posible que no lo haga en el futuro, porque deberían ser únicos. No estoy seguro de qué deberíamos recomendar en este caso para solucionar el problema, en particular para los sitios que tienen este problema. Izno ( discusión ) 21:33, 26 de septiembre de 2024 (UTC) [ responder ]
¿Para qué se utilizan las CITEREF además de como referencias de formato corto? La norma son las referencias en línea y no requerirán correcciones. Este parece ser un problema que debería solucionarse con el software. -- LCU A ctively D isinterested « @ » ° ∆t ° 21:39, 26 de septiembre de 2024 (UTC) [ responder ]
¿Para qué se utilizan las referencias CITEREF aparte de como referencias breves? Nada, que yo sepa.
Este parece ser un problema que debería ser solucionado por el software. Es decir, no se puede tener todo a la vez: o MediaWiki comprueba cada página en busca de identificadores duplicados o no lo hace. Es muy raro que MediaWiki agregue trucos para construcciones generadas por el usuario que están malformadas de una u otra manera, y especialmente no HTML malformado. Resulta que este problema se generó tanto por el hecho de que los dioses del HTML dicen que debes tener solo un identificador en cualquier página web específica, como por el hecho de que se trataba específicamente de referencias cortas en las que no sabíamos qué páginas tenían identificadores duplicados para corregir. (Presenté phab:T200517 en 2018 en base a la discusión que hizo que ref=harv fuera el valor predeterminado ).
La solución está disponible para nosotros hoy. |ref=noneSolo quiero ver si alguien más quiere aportar alguna otra sugerencia u otra posible solución alternativa.
Si ignoramos esto, también podemos identificar referencias en línea duplicadas. Izno ( discusión ) 21:53, 26 de septiembre de 2024 (UTC) [ responder ]
Esto parece un argumento a favor de restaurar |ref=harvy eliminar la compatibilidad con CITEREFla creación automática de ID. La única diferencia con el pasado sería que todas las plantillas de CS1|2 tendrían que hacer esto, incluida la que siempre tuvo la creación automática de ID.{{citation}}CITEREF
—El monje trapense ( discusión ) 21:51 26 sep 2024 (UTC) [ responder ]
Ese podría ser un enfoque válido después de que la subreferencia esté disponible por un tiempo. Personalmente, soy partidario de la generación de ID predeterminada y creo que optar por no participar con |ref=none(o quizás una nueva palabra clave, |ref=duplicateo |ref=duplicate-id) es la solución adecuada, no optar por participar a través de |ref=harv. Anticipo que en la mayoría de las páginas es raro que se genere una ID duplicada a partir de una de estas plantillas (los errores de pelusa son por instancia por página, no por listados de páginas). Izno ( discusión ) 21:57, 26 de septiembre de 2024 (UTC) [ responder ]
Si, |ref=nonefunciona y lo apoyaría |ref=duplicate.
—El monje trapense ( discusión ) 23:01 26 sep 2024 (UTC) [ responder ]
En el momento en que miré ese informe, había 169 000 artículos, ¿páginas?, pero todo lo que se puede ver es una página del informe a la vez. ¿Quién pensó que era una buena idea? cs1|2 usa <cite id="CITEREF...">...</cite>etiquetas, pero el informe no devuelve nada cuando se configura "Filtrar por nombre de etiqueta" cite. Suspiro.
Me imagino que un bot podría rastrear los artículos del informe en busca de artículos que no utilicen o hagan referencia a las plantillas que coinciden con el ID del informe, y configurarlas . Pero, ¿50 a la vez? No, no creo que vaya a escribir ese bot, es demasiado trabajo manual.{{sfn}}{{harv}}|ref=noneCITEREF
—El monje trapense ( discusión ) 23:01 26 sep 2024 (UTC) [ responder ]
Creo que la API permite más resultados, 50 es solo lo que se presenta en la interfaz de usuario, pero no sé quién ha intentado integrar estos informes. Es algo que se puede consultar en WT:LINT . Sugeriría usar Special:Search para obtener listas de artículos, pero no tiene una integración (a pesar de que se solicitó hace tiempo).
Creo que el filtro por nombre de etiqueta es exclusivo de algunos otros informes de pelusa que realmente comprueban las etiquetas (como el filtro de "etiqueta obsoleta"). Izno ( discusión ) 23:35 26 sep 2024 (UTC) [ responder ]
No, no son 169k artículos/páginas, son 169k instancias de un error ofensivo. Por lo tanto, como máximo, son 169k divididos por 2 páginas y, como mínimo, 169k divididos por 20 páginas (porque ese es el máximo identificado por el linter por página). Supongo que el linter sigue aumentando sus páginas conocidas en cuestión, ya que vi que antes eran solo 100k. :)
En cuanto a un bot de este tipo, yo añadiría el requisito de que las referencias no sean idénticas (bueno, al menos dentro de las etiquetas de referencia). Eso debería exigir un ajuste más allá de ref=none en mi opinión. Izno ( discusión ) 23:38, 26 de septiembre de 2024 (UTC) [ responder ]
En mi opinión, el informe debería corregirse o modificarse para que ignore cualquier cosa que tenga CITEREF como cadena de inicio, o al menos dar la opción de ignorar esos "errores". Los errores de duplicación de CITEREF verdaderamente problemáticos se rastrean en Category:Harv y errores de múltiples objetivos de Sfn . Headbomb { t · c · p · b } 00:15, 27 de septiembre de 2024 (UTC) [ responder ]
Lo cual es en sí mismo una plaga de falsos positivos, por lo que requiere una lista blanca completa propia. No, en realidad no los rastrea tan bien. Izno ( discusión ) 00:54, 27 de septiembre de 2024 (UTC) [ responder ]
Estás pensando en la categoría:Errores de no objetivo de Harv y Sfn , que tiene algunos falsos positivos. La categoría de error de objetivos múltiples está limpia. Headbomb { t · c · p · b } 02:14, 27 de septiembre de 2024 (UTC) [ responder ]
( editar conflicto )
No es cierto. Los errores de múltiples destinos de la categoría:Harv y Sfn solo rastrean los errores de múltiples destinos cuando se invoca el módulo:Footnotes mediante una plantilla de la familia or ; y, luego, solo aquellos identificadores que son destino de los enlaces desde una plantilla de la familia or u otro tipo de enlace.{{sfn}}{{harv}}CITEREFCITEREF{{sfn}}{{harv}}[[#CITEREF...|...]]
—El monje trapense ( discusión ) 01:06 27 sep 2024 (UTC) [ responder ]
Para su información, Special:LintErrors/duplicate-ids ahora tiene tiempo de espera:

Se superó el tiempo máximo de solicitud de 60 segundos.

[7faafbc6-d49d-4f2a-bc1d-b2e50a9b8109] 2024-09-27 01:34:03: Excepción fatal del tipo "Wikimedia\RequestTimeout\RequestTimeoutException"
FeRDNYC ( discusión ) 01:39 27 sep 2024 (UTC) [ responder ]
Joy, la consulta del espacio principal ahora también se está cayendo, sí. Izno ( discusión ) 05:18, 27 de septiembre de 2024 (UTC) [ responder ]
En este punto, creo que podemos ignorar estos errores con seguridad cuando se informan sobre la duplicación de CITEREF. Creé un ejemplo en mi entorno de pruebas. Cuando no se utiliza {{ sfn }} , no se crea confusión por identificaciones duplicadas, hasta donde puedo ver. Las notas al pie se vinculan correctamente a las citas completas correctas. Cuando se utiliza sfn, emitimos un error correctamente, ya que las citas múltiples son objetivos viables para la plantilla sfn. Ya tenemos un sistema para ver y resolver esos problemas.
Llevo seis años corrigiendo errores de Linter y, a veces, los desarrolladores de WMF, sin consultar con las personas que realmente usan su software, crean páginas de seguimiento de "errores" (o categorías, si tenemos suerte; no me hagas hablar de estas "categorías" falsas de Linter) que son menos útiles de lo que deberían. Algunas de ellas, como el seguimiento de Linter de "tabla grande", se han ocultado después de que gnomes nos comentara que había demasiados falsos positivos y errores no detectados en la lista. Tal vez las identificaciones duplicadas también puedan seguir ese camino. Actualmente aparece como "alta prioridad" en Special:LintErrors , lo que no tiene mucho sentido para mí, pero tal vez no entiendo la urgencia repentina de este seguimiento. – Jonesey95 ( discusión ) 21:07, 27 de septiembre de 2024 (UTC) [ responder ]
Teniendo en cuenta que ya había más de 3 millones de páginas en la categoría de la lista antes de que la consulta comenzara a caducar, diría que la "alta prioridad" definitivamente está descartada, sí. (¡Tres MILLONES!) FeRDNYC ( discusión ) 21:59 27 sep 2024 (UTC) [ responder ]
( editar conflicto )
Si quisieras agregar un par de referencias más a tu sandbox en algún lugar que no estén vinculadas por :{{sfn}}
<ref>{{cite book |last=Greene |first=EB |date=2020 |chapter=Chapter 1 |title=Title |page=34}}</ref>
<ref>{{cite book |last=Greene |first=EB |date=2020 |chapter=Chapter 6 |title=Title |page=169}}</ref>
luego, obtenga una vista previa de la página y mire Datos de perfil del analizador → Registros de Lua [Mostrar] puede ver la información de registro que publica Module:Footnotes cuando se publica o se obtiene una vista previa de la página. Esa información se puede mejorar para enumerar por separado los identificadores de anclaje que no están vinculados desde {{sfn/harv}}etc. Cuando hay duplicados en esa lista, Module:Footnotes puede agregar una categoría que al menos identifique los artículos que tienen identificadores duplicados no relacionados con {{sfn/harv}}. Se aplican las mismas advertencias: Module:Footnotes está creando CITEREFidentificadores a partir del wikitexto que puede ver en el artículo, por lo que las plantillas cs1|2 enterradas dentro de envoltorios de plantillas no se detectan.
—El monje trapense ( discusión ) 22:20 27 sep 2024 (UTC) [ responder ]

Autopublicado

Para aquellas ocasiones en las que se utiliza como referencia algo autoeditado (no por mí), ¿cómo formateamos el campo "editor" en la plantilla? Esto es lo que hice. Estoy intentando deshacerme de algunas entradas de aquí .  Mr.choppers |  ✎  02:10, 28 de septiembre de 2024 (UTC) [ responder ]

La solución es eliminar la ubicación, porque la ubicación es la ubicación del editor. Si no hay editor, no hay ubicación. Headbomb { t · c · p · b } 03:12, 28 de septiembre de 2024 (UTC) [ responder ]
La categoría de seguimiento dice que también puedes configurar |publisher=nonepara suprimir el mensaje. -- LCU A ctively D isinterested « @ » ° ∆t ° 10:52, 28 de septiembre de 2024 (UTC) [ responder ]
"Ninguno" es útil. Muchas fuentes tienen una ubicación pero no un editor, incluida la que formateé arriba y aquí hay otra. Gracias,  Mr.choppers |  ✎  13:45, 28 de septiembre de 2024 (UTC) [ responder ]
En las citas, la ubicación es la ubicación del editor. Si no hay editor, no hay ninguna ubicación que informar. Headbomb { t · c · p · b } 19:51, 28 de septiembre de 2024 (UTC) [ responder ]
Falso. En algunos libros muy antiguos, conocemos la ciudad en la que se publicó, pero no el editor. Un ejemplo de [2]: Girolamo Ruscelli (1566), Le imprese illustri , Venecia. En ese ejemplo en particular, archive.org [3] dice que fue impreso por la imprenta de Francesco Rampazetto, pero no encontrarás eso en la página del título y un impresor no es exactamente lo mismo que un editor. Nuestro artículo Girolamo Ruscelli cita el libro con una ubicación, pero sin editor. — David Eppstein ( discusión ) 20:05, 28 de septiembre de 2024 (UTC) [ responder ]
¿No es cierto que las fuentes autopublicadas no cumplen con los requisitos de WP:RS ? ¿Por qué molestarse en hacerlo? 𝕁𝕄𝔽 ( discusión ) 14:27 28 sep 2024 (UTC) [ responder ]
No todas las fuentes autopublicadas son RS, pero algunas podrían serlo según WP:SPS . Se podrían usar otras fuentes que no sean RS para las declaraciones WP:ABOUTSELF . -- LCU A ctively D isinterested « @ » ° ∆t ° 14:31, 28 de septiembre de 2024 (UTC) [ responder ]
También puedes poner simplemente "sin publicación", "sin editorial indicada" o "libro electrónico autoeditado" (etc.) en el campo de editorial. jengod ( discusión ) 22:09 29 sep 2024 (UTC) [ responder ]

Solicitudes de funciones

¡¡Gracias por todo lo que haces!! jengod ( discusión ) 22:17 29 sep 2024 (UTC) [ responder ]

Deberías poder insertar esta información entre el signo de cierre }} de la plantilla de cita y la </ref>etiqueta. – Jonesey95 ( discusión ) 03:40, 30 de septiembre de 2024 (UTC) [ responder ]
¡Yo hago esto con frecuencia! Pero me han informado que un exceso de plantillas hace que las páginas largas sean tristes, así que estaba pensando si se incorporara a la plantilla de citas, eso podría reducir... ¿la tristeza informática? No sé muy bien de qué estoy hablando, pero quería plantear la idea de todos modos. :) jengod ( discusión ) 03:42, 30 de septiembre de 2024 (UTC) [ responder ]
Incluyo este enlace explicativo a Ayuda: límites de plantillas sobre mi muro de texto anterior. Folly Mox ( discusión ) 10:47 30 sep 2024 (UTC)[ responder ]
Parece que lo primero requeriría algo así como un |license=parámetro, donde se podría incluir {{ source-attribution }} , {{ usgovpd }} , etc. No creo que esto realmente reduzca la cantidad de llamadas a la plantilla y, si está buscando hacer clic en un cuadro para agregar algo como esto (dentro o fuera de la plantilla CS1), el lugar para esa solicitud es, lamentablemente, mw:Talk:VisualEditor, meta:Community Wishlist o phab:.
En segundo lugar, ¿el objetivo final es que cada fuente esté anotada con un icono de candado de algún color? ¿O que cada fuente accesible en línea esté anotada con un icono de candado de algún color?
El principal problema con esto (aparte de todo el trabajo de marcar cada cita en cualquier lugar que no tenga ya un icono de candado) es que el acceso varía mucho según el usuario final. Algunas fuentes están bloqueadas por región y no tenemos forma de saber dónde se encuentra el usuario final. La mayoría de los estudiantes universitarios tendrán acceso a algunas editoriales académicas a través de suscripciones institucionales y no queremos alejarlos de buenas fuentes a las que podrían acceder a través del portal de su biblioteca con candados rojos. Los sitios web cambian sus políticas de pago, se agregan y eliminan vistas previas de Google Books (que también dependen de la región), se agregan y eliminan libros de Internet Archive, etc.
Es un problema difícil y requiere un conocimiento más profundo del estado del lector que el que el sitio web registra y pone a disposición para el análisis, así como un grado significativamente mayor de mantenimiento que requeriría un equipo a tiempo completo que revisara informes regulares de rastreadores web.
¿O la idea es simplemente agregar candados verdes a las páginas web normales? Lo siento, tengo sueño. Folly Mox ( discusión ) 10:44 30 sep 2024 (UTC) [ responder ]
¡Qué respuesta tan considerada! No había pensado en lo mucho que variarían las situaciones de los usuarios. No etiqueto todas las páginas web o artículos de noticias, pero sí etiquetaría un libro de dominio público en Google Books, la Biblioteca del Congreso o HathiTrust, simplemente porque no estoy seguro de que todo el mundo esté tan obsesionado con las fechas límite de dominio público como nosotros. Otra situación es que, de vez en cuando, encuentro algo valioso en NewspaperArchive.com en lugar de Newspapers.com. Su interfaz de usuario me resulta absolutamente confusa y todavía no he descubierto cómo compartir enlaces gratuitos a recortes de prensa, así que, a veces, por lo que es esencialmente una culpa neurótica, etiqueto esas referencias con {{acceso cerrado}}. El objetivo general subyacente se limita a la idea de una enciclopedia "gratuita": cómo podemos ayudar a las personas a acceder a información de alta calidad a un coste mínimo o nulo para ellas. Ahora nos damos por sentados a nosotros mismos (y al crecimiento masivo de Internet), pero soy mayor y cuando empezamos existía la idea de que estábamos ahorrando a la gente el tener que comprar una enciclopedia en CD-ROM de un conglomerado tecnológico, jajaja.
No es necesaria ninguna acción real, supongo que solo estoy reflexionando, pero siempre me da envidia que exista un campo de nivel de acceso de JSTOR donde se puede cambiar a "gratis", pero ese no es el caso para otros tipos de fuentes. ¡No me hagas caso y continúa! jengod ( discusión ) 13:32 30 sep 2024 (UTC) [ responder ]

Muro de pago de CNN

Entonces, CNN acaba de poner su sitio detrás de un muro de pago flexible, lo cual es lamentable. ¿Eso significa que ahora tenemos que revisar todos los artículos que actualmente citan a CNN y etiquetarlos con |url-access=limited? ¿Es eso siquiera factible o recomendable? Tal vez un bot pueda manejar eso. InfiniteNexus ( discusión ) 17:56, 1 de octubre de 2024 (UTC) [ responder ]

Me encantaría que tuviéramos bots que marcaran las fuentes de pago de la misma manera que OAbot marca las fuentes de acceso abierto. Citoid no tiene nada parecido en su funcionalidad, ni tampoco Citation bot, que yo sepa. Como resultado, casi todas nuestras citas de pago no están marcadas.
Los sitios en los que todo el dominio está detrás de un muro de pago serían un buen objetivo para la edición de bots y podrían ayudar a lograr algunos de los objetivos articulados por jengod en el hilo anterior con respecto a señalar a los estudiantes y otros investigadores indigentes en qué fuentes deberían molestarse en hacer clic.
Sin embargo, probablemente no sea el lugar adecuado. Agregar todos estos parámetros no parece polémico, pero requeriría tantas ediciones que incluso a un editor de AWB se le recomendaría que lo hiciera a través de WP:BRFA . Folly Mox ( discusión ) 18:14 1 oct 2024 (UTC) [ responder ]

Citar podcast

¿Es posible que alguien agregue "temporada" y "episodio" a los parámetros de podcast de Template:Cite ? No me siento cómodo editando yo mismo una plantilla tan ampliamente utilizada. ¿Por qué? Pregunto ( discusión ) 02:54, 2 de octubre de 2024 (UTC) [ responder ]

Necesitarás {{ cite serial }} si tu podcast tiene temporadas y episodios. Folly Mox ( discusión ) 05:44 2 oct 2024 (UTC) [ responder ]
No, no quiero citar serial . Eso se refiere a una colección de episodios y parece que le falta un parámetro para temporadas específicas y número de episodio que algo como citar episodio tiene. ¿Por qué? Pregunto ( discusión ) 11:35 2 oct 2024 (UTC) [ responder ]
Mi error, ¿por qué?, pregunto . Leí mal la documentación. También recordé mal la conversación de la última vez que se planteó esta idea aquí, en Ayuda:Estilo de cita 1/Archivo 91 § Agregar nuevos parámetros para {{citar podcast}} , donde resulta que había sugerido {{ citar episodio }} y no pasó nada más.
Tal vez sea hora de agregar |series=, |episode=, |series-url=, |series-link=a {{ cite podcast }} . Aunque alguien puede tener una mejor idea. Folly Mox ( discusión ) 12:20 2 oct 2024 (UTC) [ responder ]

idioma=es

Voy a ser sincero: estoy bastante seguro de que las citas literalmente nunca deberían especificarse |language=en(incluidas las variantes) y lo elimino con una expresión regular de las citas en cada artículo que dedico un tiempo a editar. El único caso extremo posible es cuando una fuente está en varios idiomas, donde |language=en,grces perfectamente informativo y necesario. Supongo que me pregunto si hay algo que me estoy perdiendo aquí y si hay alguna utilidad en que esto se especifique a veces. Remsense  ‥ 论09:53, 2 de octubre de 2024 (UTC) [ responder ]

He tenido la misma idea, pero resulta muy útil cuando se traduce un artículo a otro idioma. Véase, por ejemplo, Ayuda discusión:Estilo de cita 1/Archivo 93 § url-status=dead (y un tema secundario sobre language=en) . Folly Mox ( discusión ) 12:09, 2 de octubre de 2024 (UTC) [ responder ]
Las herramientas de citación automática lo añaden. Probablemente por eso es tan común. Lo he incluido de esta manera, pero nunca lo he escrito a mano. Rjj iii ( discusión ) 14:34, 2 de octubre de 2024 (UTC) [ responder ]
Cartas sobre la mesa: pregunto de la manera más totalitaria posible si alguien podría molestarse si incorporo esta expresión regular en un script de usuario publicado para uso general. La única otra cosa que se me ocurrió fue la traducción a Wikipedias en otros idiomas, pero eso parece estar fuera de nuestro alcance, aunque afortunadamente también es totalmente solucionable para los interesados. Remsense  ‥ 论22:34, 2 de octubre de 2024 (UTC) [ responder ]
No apoyaría su eliminación en masa, si algún editor lo encuentra útil, entonces debería dejarse. Lo mismo que con url-status o access-date. -- LCU A ctively D isinterested « @ » ° ∆t ° 23:05, 2 de octubre de 2024 (UTC) [ responder ]
Por supuesto, no se debe eliminar por su propio bien, me refiero a una solución de limpieza utilizada junto con otras para no generar interrupciones, para ser claros. Pero eso es lo que pregunto: ¿qué posible uso podría tener? No creo que debamos asumir que algo es potencialmente útil si no se ha presentado ninguna evidencia o argumento. Remsense  ‥ 论23:09, 2 de octubre de 2024 (UTC) [ responder ]
Si algunos editores lo encuentran útil, entonces eliminarlo no es una solución: es una preferencia personal. -- LCU A ctively D isinterested « @ » ° ∆t ° 19:23, 3 de octubre de 2024 (UTC) [ responder ]
En líneas generales estoy de acuerdo. Remsense  ‥ 论00:09, 4 de octubre de 2024 (UTC) [ responder ]
No me importaría que el script automatizado de alguien decidiera eliminarse |language=enen el transcurso de otras mejoras. Son los scripts automatizados los que nos trajeron la mayoría de estos en primer lugar, así que parece justo. Folly Mox ( discusión ) 00:58, 3 de octubre de 2024 (UTC) [ responder ]
Se ha comprobado que esta combinación de parámetros es útil. No debería eliminarse. – Jonesey95 ( discusión ) 17:42 3 oct 2024 (UTC) [ responder ]
También se ha establecido que esta combinación de parámetros es ruidosa , por citar la discusión del año pasado que vinculé arriba. No creo que deba eliminarse en masa dondequiera que se encuentre, pero los parámetros se pueden recortar al realizar mejoras en las citas existentes: las fechas completas para publicaciones de libros se pueden reducir a solo años, las fechas de acceso para medios físicos se pueden comentar, los autores y editores más allá del primero / cuarto / séptimo / lo que sea se pueden ocultar, las URL que duplican identificadores estables se pueden eliminar, los archivos de páginas de destino con muro de pago se pueden eliminar, los editores a veces se pueden eliminar, al igual que si coinciden con el dominio de origen, los códigos bibliográficos y s2cid se pueden cortar si los editores los encuentran más desordenados de lo que valen, y creo que es otra cosa que puede ir en la lista.|via=|language=en
Esto no es algo que suelo eliminar (a menos que esté haciendo una cita desde cero), pero es un caso límite: algunos editores involucrados en la traducción asistida por herramientas lo encuentran útil, algunos editores que realizan trabajos de citas en el editor de fuentes lo encuentran un desorden excesivo.
De todos modos, |language=enes probablemente lo que menos me importa de mi lista de preferencias personales , pero quería dejar constancia de una opinión contraria. Folly Mox ( discusión ) 00:39 4 oct 2024 (UTC) [ responder ]
Si no recuerdo mal, |language=ensolía hacer que Module:Citation/CS1 emitiera un mensaje de mantenimiento y había manadas de gnomos que se dedicaban a eliminar ese mensaje. Permitir y luego suprimir su visualización fue una iniciativa de los editores del grupo de trabajo de traducción de Wikipedia:WikiProject Medicine para facilitar la traducción de artículos médicos del inglés a algún otro idioma. Sí, es algo pequeño, pero si ayuda a los traductores, no es una carga para el resto de nosotros. La traducción es también la razón por la que preferimos .|language=en|language=en|language=English
—El monje trapense ( discusión ) 00:59 4 oct 2024 (UTC) [ responder ]
A continuación se muestran algunos enlaces que encontré con una búsqueda rudimentaria. La búsqueda no fue exhaustiva; estoy seguro de que hay discusiones relacionadas que están disponibles a través de otras consultas de búsqueda.
  • Archivo 30 (2017) de esta página.
  • Archivo 8 (2015) de esta página, donde SMcCandlish describió el comportamiento actual de |language=encomo razonable .
  • Módulo de discusión: Citación/CS1 (2015) en el que varios editores expusieron múltiples beneficios, entre ellos la posibilidad de copiar referencias a otras Wikipedias, la simplificación del modo en que funcionan Citoid y CheckWiki y su posible utilidad en la investigación. Doc James dijo específicamente que creo que es una buena información para proporcionar. Sí, estamos añadiendo referencias de En a casi otras 100 Wikipedias. Creo que esta es la discusión a la que Trappist se refiere inmediatamente antes.
  • Discusión:Puntos de inflexión en el sistema climático/GA1 (2022), en la que Femke dijo que los elimino con regularidad, pero este comentario me hizo pensar por qué se incluyen como predeterminados en las citas automáticas. Creo que es para traducciones; los revisores me pidieron que los incluya durante un "FAC" en nlwiki si recuerdo correctamente.
Estoy seguro de que hay más discusiones que respaldan la idea de dejarlo |language=enen las citas. – Jonesey95 ( discusión ) 01:04, 4 de octubre de 2024 (UTC) [ responder ]
Gracias, lo aprecio. Remsense  ‥ 论01:18, 4 de octubre de 2024 (UTC) [ responder ]
Para que conste, mi opinión sobre esto ha cambiado más recientemente que su enlace de discusión anterior de 2015. language=enya es el valor predeterminado para cualquier fuente citada en en.wikipedia (y cualquier otro contenido aquí), por lo que incluir esto en las citas es una hinchazón de código inútil. Al igual que el OP, elimino rutinariamente esta hinchazón cuando el valor es en[-*], a menos que haya un caso especial como |language=en,gd. (Aparte: elimino especialmente cualquier tontería como |language=en-US, etc. No tenemos ninguna necesidad de ningún tipo de tratar de identificar la variedad nacional de inglés en la que está escrita la fuente, ya que todas son mutuamente inteligibles, al lector no le importa, no sirve para ningún propósito de identificación/hallazgo/verificación de la fuente de ningún tipo, y tratar de hacerlo en primer lugar es simplemente WP:OR , a menos que el material en la fuente diga claramente algo como "Elijo escribir este artículo en inglés australiano" o lo que sea). El comentario anterior que |language=enes bastante común en las citas simplemente porque algunas herramientas lo agregan automáticamente es correcto; Todavía no he encontrado un solo editor humano que esté haciendo esto manualmente (si hay uno, deberían eliminarlo). Las herramientas que hacen esto no deberían hacerlo. (Aparte 2: Las herramientas no deberían estar haciendo un montón de otras cosas malas que varias de ellas están haciendo, como usar |year=en lugar de |date=, poner nombres de sitios web en |publisher=lugar de |work=AKA |website=, codificar incorrectamente los nombres de los autores como |author=Jane D. Smithen lugar de |first=Jane D.|last=Smith, o hacer cosas aún más incorrectas como |author=Jane D. Smith & Philbert Gonzalezo |author=Mikael von Bek (Amsterdam Correspondent)o |author=Newsroom staff, etc.) Hace un año o tres, alguien intentó argumentar aquí que incluir |language=enera de alguna manera necesario para la traducción, pero el examen de este asunto no demostró que tal afirmación fuera cierta. Si está escribiendo un script para convertir citas de Wikipedia en inglés a ruso (o lo que sea), simplemente usa el equivalente de la plantilla ru.WP |language=enpara cualquier cita aquí que carezca de un código de idioma, al igual que alguien en este sitio que escriba un script para convertir desde citas rusas asignará naturalmente |language=rude manera predeterminada a las citas rusas que carezcan del equivalente de la plantilla de citas rusas |language=ru. Esto no es ciencia espacial.  —  SMcCandlish ☏ ¢  😼  05:31, 4 de octubre de 2024 (UTC) [ responder ]
Supongo que mi última palabra es que el parámetro parece tener un valor marginal o nulo para casi todos los editores, y aunque me alegra que ayude en la traducción, desearía que la responsabilidad de facilitar herramientas de traducción sólidas no se impusiera parcialmente al wikitexto, que de otro modo está destinado a servir a un conjunto de propósitos completamente diferente. Sin embargo, confío en que sirva de ayuda, así que no quiero irritar más a nadie por ello. Remsense  ‥ 论05:36, 4 de octubre de 2024 (UTC) [ responder ]

'*' en la marca de tiempo de la URL del archivo

De la contabilidad forense :

Godbole, Pradeep. "Metodologías de investigación de fraudes y estructuración de informes" (PDF) . WIRC-ICAI . Consultado el 23 de septiembre de 2024 . {{cite web}}: |archive-url=está mal formado: bandera ( ayuda )CS1 maint: url-status (link)

El problema es https://web.archive.org/web/20230601000000*/específicamente el "*". El uso de '*' en una marca de tiempo es técnicamente correcto. Hay al menos 85 (tiempos de búsqueda agotados). Podría eliminarlos, no son la mejor práctica, en la mayoría de los casos innecesarios, pero hay un caso de nicho si la cita se refiere a la propia Wayback Machine para mostrar una serie de instantáneas para establecer algún hecho. Al revisar los casos existentes, no puedo encontrar ninguno que sea legítimo para ese caso de nicho. Pero tampoco son URL rotas. ¿Cómo queremos manejarlas si producen un error y se rastrean en Category:CS1 errors: archive-url ? No lo creo porque las URL funcionan (no están malformadas) y puede haber algunos casos de uso legítimos. -- Green C 16:10, 2 de octubre de 2024 (UTC) [ responder ]

El uso de un splat en la marca de tiempo puede ser técnicamente correcto , pero ¿qué propósito tiene en la posición 15 (subsegundo)? ¿Wayback Machine admite instantáneas de archivo en intervalos de subsegundo? cs1|2 rechaza el splat porque cuando aparece dentro de los catorce caracteres de una marca de tiempo, Wayback Machine se vincula a una pantalla de calendario que ofrece al lector múltiples instantáneas posibles. Eso realmente no es lo que queremos. Queremos un enlace a una única instantánea que respalde el texto de nuestro artículo.
En cuanto al caso específico, si la cita se refiere a la propia Wayback Machine para mostrar una serie de instantáneas para establecer algún hecho , la URL para esa visualización del calendario debería estar en . Sin duda, otro servicio de archivo podría archivar la visualización del calendario de Wayback Machine, cuya URL debería estar en .|url=|archive-url=
—El monje trapense ( discusión ) 18:14 3 oct 2024 (UTC) [ responder ]
La estrella en la posición 14 o 15 envía al espectador a la página de índice: este 15 contra ese 14. Se podría hacer que el enlace de Wayback sea el principal, |url=aunque esto se hace tan a menudo de forma incorrecta (mirando reFill) que varias herramientas y bots lo mueven automáticamente a la URL del archivo, por lo que no durará mucho en la práctica, a menos que exista algún mecanismo para marcar la excepción y la cooperación de las herramientas y los bots. En cualquier caso, si es una marca de tiempo de 15 caracteres la que está causando problemas, ¿por qué no incluir la estrella como una de las cadenas de indicadores, como este indicador, que no activa el error de límite de 14? -- Green C 23:40, 3 de octubre de 2024 (UTC) [ responder ]
No es el límite de longitud de la marca de tiempo de 14 dígitos lo que cs1|2 rechaza, sino el signo que aparece en cualquier parte de la marca de tiempo. Esto, por ejemplo, utiliza una marca de tiempo de 8 dígitos con un signo; termina en el mismo lugar que la marca de tiempo de 14 dígitos con un signo:
{{Cite web |title=Fraud Investigation Methodologies and Report Structuring |url=https://wirc-icai.org/images/material/Investigation-Methodologies-Report-Structuring.pdf |url-status=deviated |archive-url=https://web.archive.org/web/20230601*/https://wirc-icai.org/images/material/Investigation-Methodologies-Report-Structuring.pdf |archive-date=2023-06-01}}
"Metodologías de investigación de fraude y estructuración de informes" (PDF) . {{cite web}}: |archive-url=está mal formado: marca de tiempo ( ayuda )CS1 maint: url-status (link)
El splat es un indicador de un editor demasiado perezoso para especificar la instantánea exacta que respalda el texto en nuestro artículo.
¿Por qué no incluir la estrella como una de las cadenas de banderas ? Porque no es una cadena de banderas, por lo que no debería tratarse como tal.
—El monje trapense ( discusión ) 00:32 4 oct 2024 (UTC) [ responder ]
Oh, pensé que algunos editores querían el índice de vez en cuando porque citan un rango de fechas de instantáneas para respaldar un hecho, como un sitio web que funcionó hasta una fecha determinada después de la cual dejó de funcionar (como ejemplo). Si nuestro objetivo es eliminar los splats por completo, es fácil de ejecutar. -- Green C 00:50, 4 de octubre de 2024 (UTC) [ responder ]

Edición de documentación enPlantilla:Citar web

Actualmente, en la sección Uso , el conjunto de parámetros completo en blanco en formato horizontal utiliza "|last= |first= |author= |author-link=" en lugar de "|last1= |first1= |author1= |author-link1=".

Si bien last o last1 funcionan, ¿sería mejor para mantener la coherencia con la documentación de otras plantillas de citas como Template:Cite book y Template:Cite news, donde en el "Conjunto completo de parámetros en formato horizontal" se usa last1, etc.? ¿O incluso cambiar y usarlo en todos los ejemplos y parámetros en blanco? 🌿 Mt B o t a n y ( discusión ) 22:24 3 oct 2024 (UTC) [ responder ]

La documentación no está protegida. Si cree que la documentación se puede mejorar, hágalo.
—El monje trapense ( discusión ) 22:31 3 oct 2024 (UTC) [ responder ]
Gracias, me di cuenta de eso, pero soy un editor que "pregunta primero" si algo parece más crítico que lo que edito habitualmente. La historia sobre el nuevo administrador que eliminó la página principal es una historia de advertencia que he tomado como que solo porque puedo, no significa que siempre deba hacerlo. He actualizado la página horizontal completa, pero voy a ver si alguien habla para objetar antes de hacer algo más que eso. 🌿 Mt B o t a n y ( discusión ) 23:09, 3 de octubre de 2024 (UTC) [ responder ]

¿Marcado para parámetros?

@ BlaueBlüte : He estado usando {{ para }} en mis ediciones. Noté que BlaueBlüte usó {{code|{{!}}publisher{{=}}self-published}} (renderizado como |publisher=self-published) en lugar de (renderizado como ). ¿Hay alguna razón para preferir el primero? -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 10:31, 4 de octubre de 2024 (UTC) [ responder ]{{para|publisher|self-published}}|publisher=self-published

Ambos funcionan igual. {{ para }} es básicamente una versión más rápida de hacer lo que hizo BlaueBlüte. Headbomb { t · c · p · b } 10:48, 4 de octubre de 2024 (UTC) [ responder ]
Sí, pero mi pregunta era si hay alguna razón para no usar la versión más rápida, o si está bien seguir usándola. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 12:17 4 oct 2024 (UTC) [ responder ]
Cuando las cosas se presentan de la misma manera, cada uno es libre de escribir las cosas como prefiera. Puedo escribir Pokémon o Pokémon. Tampoco sabrás de qué manera escribí a menos que inspecciones el código. Headbomb { t · c · p · b } 12:23, 4 de octubre de 2024 (UTC) [ responder ]
@ Chatul , siéntete libre de cambiarlo si {{para}}es el método de marcado más comúnmente usado en las documentaciones de plantillas CS1. Hay algo que decir sobre la consistencia del código incluso cuando el resultado renderizado es el mismo. ― BlaueBlüte ( discusión ) 17:06, 4 de octubre de 2024 (UTC) [ responder ]

¿Debería permitirse que la revista Cite?ambos"paginas=" y "pagina="?

La inclusión de "pages=" y "page=" se considera un error, pero tiene sentido permitir ambos, dando los números de página de inicio y final en un artículo, y también la página específica en la que aparece algún contenido. Un ejemplo es <ref name="Abrahamson1976">{{cite journal | last = Abrahamson | first = James L | year = 1976 | title = David Starr Jordan and American Antimilitarism | jstor = 40489774 | journal = [[The Pacific Northwest Quarterly]] | volume = 67 | issue = 2|url=https://www.jstor.org/stable/40489774| pages = 76–87|page=79}}</ref>, utilizado en el artículo David Starr Jordan , donde el contenido respaldado por el artículo está en la página 79 de un artículo de 12 páginas. ¿O es mejor simplemente citar la página que respalda el texto? He tratado este tema en el artículo añadiendo "P. 79" a la cita que indica el rango de páginas. Pero permitir ambos parámetros es problemático si se requieren varias páginas en el artículo para respaldar el texto; tal vez no necesitemos citar el rango, o añadir las páginas relevantes después de la plantilla, por lo que no se requiere ningún cambio en la plantilla, tal vez una nota en la documentación. Saludos cordiales, Pol098 ( discusión ) 14:48, 5 de octubre de 2024 (UTC) [ responder ]

Yo diría que casi siempre se trata de información innecesaria, por ejemplo, para especificar tanto el rango de páginas de un capítulo de un libro o un artículo de una revista, como las páginas que se citan. Lo que se permite es tanto |page(s)=y |quote-page(s)=, donde puedes especificar tanto el rango completo que se cita como la ubicación específica de la cita directa que también has incluido en la cita. Remsense  ‥ 论15:02, 5 de octubre de 2024 (UTC) [ responder ]
Esa es una buena teoría. ¿Qué se hace en la práctica? ¿Qué se hace en el autocompletado de citas?
Los nombres de los parámetros sí importan. SamuelRiv ( discusión ) 15:29 5 oct 2024 (UTC) [ responder ]
¿Disculpe? Remsense  ‥ 论15:30, 5 de octubre de 2024 (UTC) [ responder ]
Creo que el comentario de SamuelRiv significa que la diferencia entre "página" y "páginas", aunque a veces se ignore, es importante. Pol098 ( discusión ) 21:42 5 oct 2024 (UTC) [ responder ]
En cierto modo, pero no exactamente. Estoy diciendo que, en particular, cuando los editores usan {{cite journal}}, rellenarán |pages=con el rango completo de páginas del artículo, como se hace en las citas típicas de revistas impresas. La plantilla de autocompletar también tiende a hacer esto, la última vez que lo revisé. Que este comportamiento no sea correcto no es obvio a partir de los nombres de los parámetros; de hecho, uno asumiría que la plantilla podría distinguir fácilmente de manera automática entre una sola página y varias páginas (y ajustar la salida "p." vs "pp." en consecuencia), ya que CS1 suele ser sofisticado en este sentido.
Los editores responden instintivamente a los nombres de los parámetros y aprenden de los ejemplos existentes en los artículos, así que, al ver tanto |page=y |pages=, ¿qué haría un editor típico? Lo ideal sería que tuviéramos estadísticas del uso "incorrecto" de los robots de corrección de citas.
Pero, por experiencia, esto es lo que sucede en la práctica, y es bastante fácil de abordar: reemplace el |pages=parámetro con algún otro nombre, o elimínelo, y haga que CS1 detecte automáticamente los plurales (como ya lo hace en un passthru para detectar la sintaxis del rango de páginas). Para abordar a los editores que realmente desean colocar un rango de páginas bibliográficas en algún lugar, tenga parámetros de inicio de página (o más fin de página) y decida no mostrarlos si realmente lo desea. SamuelRiv ( discusión ) 22:09, 5 de octubre de 2024 (UTC) [ responder ]
En pocas palabras, no. Si necesitas especificar ambos, el formato es |pages=76–87 [79]. Headbomb { t · c · p · b } 15:55, 5 de octubre de 2024 (UTC) [ responder ]
También he hecho/visto |pages=1–85 at p. 59, |pages=39–71 (esp. pp. 41–42)etc. La gente sobrecarga mucho el parámetro debido a la imposibilidad de proporcionar tanto una extensión de página completa como una ubicación de información de respaldo específica (a menos que, como se indica, también se incluya una cita en la plantilla).
Sé que Citation Bot solía sobrescribir números de página específicos con la extensión completa de la página del artículo o capítulo que se citaba, pero creo que eso se solucionó el año pasado. Las herramientas automatizadas a veces pueden seguir haciendo esto si no están programadas para evitar sobrescribir los valores de los parámetros existentes, pero no las controlo todas ni uso ninguna.
Probablemente sería más seguro poder especificar tanto una extensión de página completa como páginas de soporte específicas para que no tengamos que depender de que los futuros codificadores se den cuenta de que el |page=parámetro que sus herramientas están modificando puede ser intencionalmente específico en lugar de un "error", ya que no coincide con su base de datos.
Me imagino que la implementación más sencilla sería algún alias |quote-page=que no dependa de la presencia de |quote=. En realidad, no tengo ninguna opinión muy clara, ya que sobrecargar el parámetro funciona bien para nuestros propósitos. Folly Mox ( discusión ) 18:18, 5 de octubre de 2024 (UTC) [ responder ]
Los números de página de las citas de revistas deben ser el rango de páginas del artículo completo de la revista, punto. Cualquier otra información que especifique la ubicación de la referencia dentro del artículo debe especificarse en otro lugar, ya sea mediante una cita o fuera de la plantilla de cita. Tenga en cuenta que la paginación de los artículos de revistas con frecuencia difiere de la paginación de sus preimpresiones y la paginación de sus reimpresiones (en libros de obras recopiladas y similares), y la paginación puede no ser visible en absoluto para los lectores de las versiones en línea HTML de los artículos de revistas. Por lo tanto, cuando sea posible, las ubicaciones más específicas deben describirse de otras formas, por ejemplo, mediante números de sección y títulos en lugar de páginas. — David Eppstein ( discusión ) 18:41, 5 de octubre de 2024 (UTC) [ responder ]
No había considerado esos casos, gracias por darme una pista de por qué puede ser claramente deseable. Remsense  ‥ 论21:10, 5 de octubre de 2024 (UTC) [ responder ]
Lo que me parece infinitamente fascinante es cómo esto es completamente contrario a la documentación de CS1.
(Sé que nos han dicho que editemos la documentación, pero como vemos aquí, hay un desacuerdo fundamental sobre lo que realmente hacen los parámetros, un desacuerdo entre la teoría y la práctica, y cierto desacuerdo sobre si se debe considerar la práctica). SamuelRiv ( discusión ) 22:16 5 oct 2024 (UTC) [ responder ]
Pol098 , también puedes usar {{ rp }} después de la <ref>etiqueta de cierre, como {{rp|79}}. {{ rp }} se usa ampliamente y casi no gusta. La futura extensión de subreferencia de WMF puede abordar situaciones como esta. Folly Mox ( discusión ) 19:14 5 oct 2024 (UTC) [ responder ]
{{ rp }} es excelente, lo recomiendo encarecidamente. DuncanHill ( discusión ) 20:27 5 oct 2024 (UTC) [ responder ]
{{ rp }} es una maldita plaga de horrores. Cualquier otra alternativa es mejor. Headbomb { t · c · p · b } 20:42, 5 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo. Es una abominación. — David Eppstein ( discusión ) 21:06 5 oct 2024 (UTC) [ responder ]
Puntos interesantes en respuesta a mi sugerencia. Si bien uso {{ rp }} (lo siento), no creo que sea ideal en este caso. Lo que saco en claro es que "pages=" se puede sobrecargar sin error; y que un número de página específico puede volverse incorrecto con la republicación, etc. (al igual que una referencia a un libro que no está vinculado a una edición y editorial en particular). Saludos cordiales, Pol098 ( discusión ) 21:39 5 oct 2024 (UTC) [ responder ]

Título original de una obra traducida

Dado que hay parámetros dedicados a señalar a los traductores, ¿existe también una manera (aparte de soluciones alternativas como la que acabo de utilizar en Fonología serbocroata ) de señalar el título original de una obra traducida, y también el idioma original de la obra? Todos los demás parámetros relacionados con la traducción se refieren a traducciones que los propios editores de Wikipedia proporcionan para obras en idiomas distintos del inglés (estándar), pero me refiero a obras que ya están presentes en la traducción (normalmente al inglés). -- Florian Blaschke ( discusión ) 22:28 11 oct 2024 (UTC) [ responder ]

Normalmente, proporcionaría citas completas tanto del trabajo original como de la traducción. Kanguole 22:36, 11 de octubre de 2024 (UTC) [ responder ]
 Enlace de cortesía:  Special:Diff/1250687271
También proporcionaré una cita completa del trabajo original, si se considera importante mencionar el trabajo original en su totalidad.
A menudo, simplemente cambio los parámetros |title=y |trans-title=, de modo que el título original aparezca entre corchetes después del título en inglés elegido por los traductores y su editor. En estos casos, omitiré el idioma original de la obra, que por lo general no importa. Folly Mox ( discusión ) 16:54 12 oct 2024 (UTC) [ responder ]
No estoy convencido de que sea una buena idea utilizar un parámetro en contra de su propósito documentado. La documentación de |trans-title=in está aquí . Si la fuente con título en inglés es la fuente que se consultó, poner el título en el idioma original solo crea confusión y trabajo inútil para los editores posteriores. Si consultó tanto el original como la traducción, cítelos a ambos, pero cítelos por separado; no intente mezclar dos fuentes con detalles bibliográficos (probablemente) completamente diferentes en una sola plantilla. Las plantillas cs1|2 no están diseñadas para eso.{{cite book}}|trans-title=
—El monje trapense ( discusión ) 18:33 12 oct 2024 (UTC) [ responder ]
Gracias por la aclaración, trapense. Dejaré de practicarlo. ¿Tienes alguna sugerencia sobre cuál es la mejor manera de incluir esta información si no se consultó la versión original (como parece ser el caso aquí)? Folly Mox ( discusión ) 20:06 12 oct 2024 (UTC) [ responder ]
§¿Lectura adicional? ¿Pero por qué? Esta es la Wikipedia en inglés; incluir una fuente que la mayoría de nuestros lectores no podrán leer y que no fue consultada al escribir el artículo me parece algo así como: ¡Dios mío! ¡Hay una casilla vacía! ¡Tengo que llenarla! Si el artículo trata sobre el autor o sobre esta fuente en particular, entonces, por supuesto, incluya la versión en el idioma original. ¿Para artículos sobre otros temas? No veo la necesidad.
—El monje trapense ( discusión ) 21:20 12 oct 2024 (UTC) [ responder ]

El campo "otros" no acepta el contenido especificado

Saludos y felicitaciones. En Lore_Segal#Work hay nueve citas de libros que usan "others = Illustrated by ___" como se especifica en las instrucciones, pero las citas siguen generando errores. ¿Hay algún error en la forma en que se ingresó la información o en las instrucciones, o en realidad hay un error? — DocWatson42 ( discusión ) 23:28 12 oct 2024 (UTC) [ responder ]{{Cite book}}

Los mensajes de mantenimiento no son errores. |others=, por su propio nombre, implica que hay 'otros' colaboradores. Se espera que las plantillas de cs1|2 estén completas. A esta, por ejemplo, le falta un autor:
{{cite book|title = Tell Me a Mitzi|date = 1970|others = Illustrated by Harriet Pincus|lccn = 69014980|publisher = [[Farrar, Strauss and Giroux]]}}
Cuéntame una Mitzi . Ilustrado por Harriet Pincus. Farrar, Strauss y Giroux . 1970. LCCN  69014980.{{cite book}}: CS1 maint: others (link)
Se supone que Segal es el autor, pero cualquiera que lea esa plantilla de forma aislada no lo sabría. Si Segal es el autor, escriba la plantilla de esta manera para incluir toda la información bibliográfica necesaria y que se muestre como lo hace la plantilla rota (sin mensaje):
{{cite book |last=Segal |first=Lore |display-authors=0 |title=Tell Me a Mitzi |date=1970 |others=Illustrated by Harriet Pincus |lccn=69014980 |publisher=[[Farrar, Strauss and Giroux]]}}
Cuéntame una Mitzi . Ilustrado por Harriet Pincus. Farrar, Strauss y Giroux . 1970. LCCN  69014980.
Lo anterior garantiza que todos los metadatos necesarios estén presentes:
'"`UNIQ--templatestyles-000000BE-QINU`"'<cite id="CITEREFSegal1970" class="citation book cs1">''Tell Me a Mitzi''. Illustrated by Harriet Pincus. [[Farrar, Strauss and Giroux]]. 1970. [[LCCN (identifier)|LCCN]]&nbsp;[https://lccn.loc.gov/69014980 69014980].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Tell+Me+a+Mitzi&rft.pub=Farrar%2C+Strauss+and+Giroux&rft.date=1970&rft_id=info%3Alccn%2F69014980&rft.aulast=Segal&rft.aufirst=Lore&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
—El monje trapense ( discusión ) 00:33 13 oct 2024 (UTC) [ responder ]
Ah, eso es lo que me estaba perdiendo. Gracias. ^_^ — DocWatson42 ( discusión ) 08:09 13 oct 2024 (UTC) [ responder ]

Citar algo publicado conjuntamente por una obra y una no obra

Para {{ Infobox US university ranking }} , esta cita corresponde a una publicación realizada conjuntamente por The Wall Street Journal (que debería estar en cursiva como trabajo) y College Pulse (que no debería estar en cursiva). ¿Hay alguna forma de usar los parámetros |work=y |publisher=para que The Wall Street Journal /College Pulse se muestren en la cita de alguna manera? Sdkb talk 16:01, 15 de octubre de 2024 (UTC) [ responder ] 

A mí me parece una solución razonable, o |publisher=College Pulse |via=Wall Street Journal Folly Mox ( discusión ) 16:19 15 oct 2024 (UTC) [ responder ]
Eso me parece una solución razonable. No presenté una solución, así que no estoy seguro a qué te refieres. La visualización que quiero generar es la que aparece en el texto de cita verde anterior. No creo que una combinación estándar |work=y (o y ) sea apropiada, ya que implicaría falsamente que College Pulse es el editor del WSJ (y la combinación via implicaría que WSJ republica contenido de College Pulse en lugar de ser coautor del mismo). Sdkb talk 16:43, 15 de octubre de 2024 (UTC) [ responder ]|publisher=|publisher=|via= 
Entendí mal. Pensé erróneamente que estabas sugiriendo |work=Wall Street Journal |publisher=College Pulse. Es cierto que esto arruinaría un poco los metadatos, pero parece que tendría sentido visualmente. Parece que hay mejores ideas a continuación. Folly Mox ( discusión ) 18:01 15 oct 2024 (UTC) [ responder ]
¿Cuál de ellos consultó? Cítelo ( WP:SAYWHEREYOUGOTIT ). Si consultó ambos, cítelos, pero por separado. cs1|2 no está diseñado para citar múltiples fuentes con una sola plantilla.
—El monje trapense ( discusión ) 17:12 15 oct 2024 (UTC) [ responder ]
Del sitio web citado se desprende que "WSJ/College Pulse Rankings" es el título de una serie publicada (que a menudo también se publica en otros medios, de forma similar a los rankings de US News y otros), por lo que sería bueno para un |work=campo, con |title=2025 Best Colleges in the U.S., mientras que WSJ en este caso, debido a que es el anfitrión oficial de este medio, es probablemente el |publisher=. Intentaría utilizarlo |via=solo para un anfitrión terciario. SamuelRiv ( discusión ) 17:19 15 oct 2024 (UTC) [ responder ]
Si se utiliza el campo de editor, el WSJ no tendrá cursiva. Sdkb  talk 18:01, 15 de octubre de 2024 (UTC) [ responder ]