stringtranslate.com

Ayuda para hablar:Estilo de cita 1

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 ]

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 de octubre de 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 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"páginas=" y "página="?

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-000000F0-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 ]

Actualización del valor PMID

Actualmente aparece un error al intentar citar el siguiente artículo debido a que el PMID está fuera de rango: https://pubmed.ncbi.nlm.nih.gov/39401844/

¿Esta página de ayuda dice que hay que informar el problema aquí? No es válida si se elimina ( discusión ) 13:53, 17 de octubre de 2024 (UTC) [ responder ]


Citar tesis

Sería bueno si esto completara una jerarquía de categorías ocultas, con nodos de hoja como "Categoría:Páginas que incluyen citas de títulos de maestría" completados por degree=masters|MSC|MBA, etc. Debería haber un depósito para los tipos no reconocidos y el sistema debería ser fácil de ampliar.

La motivación es que, en general, no deberíamos utilizar maestrías como citas (ni tampoco tesis doctorales, aunque éstas son menos preocupantes), sino utilizar trabajos publicados.

Todo lo mejor: Rich Farmbrough 12:57, 18 de octubre de 2024 (UTC).[ responder ]

También hay tesis de licenciatura/tesis de clase de pregrado que deberíamos tener en cuenta si comenzamos a llevar un registro de ellas.
Ya que estamos en el tema, me gustaría que se emitiera un error si no se especifica el tipo de grado. Headbomb { t · c · p · b } 13:09, 18 de octubre de 2024 (UTC) [ responder ]
Solo por curiosidad, repetí esta búsqueda para |degree=y la primera letra del valor asignado. A excepción de K, N, O, Q y V–Z, todas las búsquedas con letras iniciales arrojaron resultados. No parece haber mucha coherencia. No repetí estas búsquedas para |type=.
{{cite thesis}}se utiliza en aproximadamente 36.500 artículos. De ellos, ~11.000 utilizan |degree=y ~15.200 utilizan |type=. |type=y |degree=son alias parciales; |degree=hace que Module:Citation/CS1 añada 'Thesis' al valor asignado a |degree=.
Si hiciéramos esto, probablemente tendríamos dos categorías de propiedades: una para |degree=y otra para |type=. Los artículos en las categorías deberían ordenarse por el primer carácter del valor asignado.
Pero ¿deberíamos hacerlo? ¿Alguien va a hacer algo de forma activa con los datos que se recopilan? La experiencia pasada dice que no se hará nada con estos datos.
Exigir {{cite thesis}}tener |degree=(preferiblemente) o |type=parece razonable.
—El monje trapense ( discusión ) 13:51 18 oct 2024 (UTC) [ responder ]
Las tesis de licenciatura y de grado deberían al menos etiquetarse como {{ bsn }} , pero mantener categorías para todos los tipos de títulos parece bastante innecesario. Folly Mox ( discusión ) 14:18 18 oct 2024 (UTC) [ responder ]
Agregar (o cualquier otra plantilla) está fuera del alcance de Module:Citation/CS1 . Los editores no han optado por ser ni siquiera pasablemente consistentes con el valor que asignan, por lo que no es posible que cs1|2 categorice solo las tesis de licenciatura y de pregrado; es por eso que sugerí ordenar las categorías por la letra inicial del valor asignado al parámetro. Y nadie aquí ha sugerido categorías de mantenimiento (todavía).{{bsn}}|degree=
—El monje trapense ( discusión ) 14:38 18 oct 2024 (UTC) [ responder ]
Si quieres una sugerencia de categoría explícita, supongo que sería Categoría: Error CS1: falta título o algo así. Headbomb { t · c · p · b } 15:49, 18 de octubre de 2024 (UTC) [ responder ]
Trappist the monk, seguro, no quise sugerir que el módulo debería agregar plantillas de citas en línea automáticamente. Estaba respondiendo a la pregunta sobre si alguien va a hacer algo activamente con los datos que se recopilan . Disculpas por la falta de comunicación. Folly Mox ( discusión ) 16:12 18 oct 2024 (UTC) [ responder ]
En todo esto, recordemos que {{ cite thesis }} y otras plantillas de citas no siempre se utilizan para respaldar afirmaciones en el texto de un artículo. Las plantillas de citas se utilizan a menudo en listas de trabajos escritos por una persona, en cuyo caso una etiqueta como {{ bsn }} no sería aplicable. – Jonesey95 ( discusión ) 16:24, 18 de octubre de 2024 (UTC) [ responder ]

La mejor plantilla para citar una página web derivada de un libro

Recientemente noté que otro editor citaba una de mis páginas web favoritas, Flora of North America, utilizando la plantilla cite encyclopedia en lugar de cite web , como he estado haciendo yo. ¿Sería más correcto utilizar cite book o cite encyclopedia en lugar de cite web para esta fuente porque se publicó por primera vez en formato de libro? 🌿 Mt B o t a n y ( discusión ) 16:34 19 oct 2024 (UTC) [ responder ]

En este caso particular, creo que es mejor citarlo como un sitio web, llamándolo por ejemplo "Flora of North America Online", porque, como se indica aquí, algunas de las páginas web han cambiado con respecto a las versiones impresas anteriores. Peter coxhead ( discusión ) 17:03 19 oct 2024 (UTC) [ responder ]
Gracias Peter. Me lo imaginaba, pero es mejor preguntar que adivinar. 🌿 Mt B o t a n y ( discusión ) 17:28 19 oct 2024 (UTC) [ responder ]

Título=ninguno en citas de periódicos y revistas

En {{ cite journal }} (y ​​{{ citation }} con journal=), cuando no hay una URL o un enlace al título, es aceptable utilizar title=none para suprimir el título. Esto es útil en casos en los que no hay título o el título sería redundante, como en el caso de las reseñas de libros en las que no existe un título real (la reseña solo está encabezada por unas pocas líneas de metadatos sobre el artículo que se está revisando) o en los casos en los que varias reseñas se agrupan y, de lo contrario, se les daría el mismo título repetido y redundante.

Con menos frecuencia, esto también sería útil para {{ cite news }} y {{ cite magazine }} . Un ejemplo de esto es Freshman's dream , donde (para demostrar la amplia difusión de la idea del tema en el momento de su publicación original en 1938), una referencia enumera la publicación del periódico original con su título y luego cuatro publicaciones posteriores del mismo artículo, con el título deliberadamente eliminado. En este caso, el código fuente de Freshman's dream incluye un código muy complicado para ocultar los mensajes de error CS1 visibles que se generarían al omitir los títulos, pero no suprime la categoría de error que también se genera. Sería mucho más limpio si se pudieran formatear con title=none, pero eso no funciona: para citas de noticias o revistas (en este caso, generadas por {{ citation }} y el parámetro newspaper= o magazine= ), esto produce un "none" visible real en la posición del título en la cita.

Una alternativa para el sueño de Freshman sería hacer como si todas estas fueran revistas y usar la capacidad de citación de revistas para establecer title=none. Una segunda alternativa sería renunciar a las plantillas de citas por no poder manejar nada que no sea una fórmula y formatear las citas manualmente. Una tercera alternativa sería modificar el código de la plantilla para que sea menos inflexible y permitir title=none para esas citas. O tal vez haya una cuarta alternativa que he pasado por alto. No creo que sea aceptable forzar estas citas a tener títulos, ni tratar de extender el código chapucero que ya está allí para suprimir también la categoría. ¿Son posibles la tercera o cuarta alternativa, o tenemos que renunciar al uso de plantillas de citas? — David Eppstein ( discusión ) 01:11, 20 de octubre de 2024 (UTC) [ responder ]

David Eppstein , no quiero hacer comentarios sobre el contenido de este asunto, pero sí suprimí la categoría de error utilizando un método que no es muy complicado (además de implementar un cambio de formato posiblemente dudoso). No dudes en volver a escribir si lo deseas. Folly Mox ( discusión ) 16:36 20 oct 2024 (UTC) [ responder ]
¡Gracias! Cuarta alternativa: no-tracking =y. Aún tenemos el código de eliminación de mensajes de error que sería bueno evitar, pero eso es menos urgente. — David Eppstein ( discusión ) 16:40, 20 de octubre de 2024 (UTC) [ responder ]