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 usurped
fuente etiquetada, se muestra esta advertencia en la parte superior:
Además, en mi caso, las usurped
referencias etiquetadas con - tienen este bit etiquetado al final:
El bot GreenC ha estado marcando (correctamente) miles de URL como usurped
parte 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)
Esta categoría de seguimiento oculta enumera páginas con citas CS1 que utilizan
|url-status=usurped
o|url-status=unfit
.Las palabras clave
unfit
yusurped
tienen 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
unfit
yusurped
se 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.
{{ICD10}}
{{ICD11}}
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.
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...".
unfit
usurped
|url-status=usurped
/ |url-status=unfit
son (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 .{{medical resources}}
| url-status=usurped
. Que tenga un buen día, Manifestación ( discusión ) 13:36, 4 de octubre de 2024 (UTC) ¡¡Gracias por todo lo que haces!! jengod ( discusión ) 22:17 29 sep 2024 (UTC)
</ref>
etiqueta. – Jonesey95 ( discusión ) 03:40, 30 de septiembre de 2024 (UTC) |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) 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)
¿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)
|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) 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,grc
es 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)
|language=en
en 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) 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=en
es 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) |language=en
solí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
|language=en
como razonable.
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.
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.
|language=en
en las citas. – Jonesey95 ( discusión ) 01:04, 4 de octubre de 2024 (UTC) language=en
ya 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=en
es 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. Smith
en lugar de |first=Jane D.
|last=Smith
, o hacer cosas aún más incorrectas como |author=Jane D. Smith & Philbert Gonzalez
o |author=Mikael von Bek (Amsterdam Correspondent)
o |author=Newsroom staff
, etc.) Hace un año o tres, alguien intentó argumentar aquí que incluir |language=en
era 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=en
para 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=ru
de 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) {{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)
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.
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=
|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) {{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}}
¿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.
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)
@ 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) {{para|publisher|self-published}}
|publisher=self-published
{{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) 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)
|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) {{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.|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.|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) |pages=76–87 [79]
. Headbomb { t · c · p · b } 15:55, 5 de octubre de 2024 (UTC) |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) <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) 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)
|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) |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=
¡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.
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) {{Cite book}}
|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]]}}
{{cite book}}
: CS1 maint: others (link){{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]]}}
'"`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]] [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>
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)
|publisher=College Pulse
|via=Wall Street Journal
Folly Mox ( discusión ) 16:19 15 oct 2024 (UTC) 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) |publisher=
|publisher=
|via=
|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) 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)
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).
|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=
.|degree=
y otra para |type=
. Los artículos en las categorías deberían ordenarse por el primer carácter del valor asignado.{{cite thesis}}
tener |degree=
(preferiblemente) o |type=
parece razonable.{{bsn}}
|degree=
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)
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)
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)