Esta es una revisión anterior de esta página, editada porSeraphimblade ( charla | contribuciones ) a las 18:13, 5 de septiembre de 2020 ( → Dejar de lado las citas entre paréntesis : cierre final con declaración ) . La dirección actual (URL) es un enlace permanente a esta revisión, que puede diferir significativamente de la revisión actual .
Política | Técnico | Propuestas | Laboratorio de ideas | WMF | Diverso |
- Primera discusión
- Nueva publicación
Aquí se discuten nuevas propuestas. Antes de enviar :
Las discusiones se archivan automáticamente después de permanecer inactivas durante nueve días. |
«Archivos , 162 , 163 , 164 , 165 , 166 , 167 , 168 , 169 , 170 , 171 , 172 , 173 , 174 , 175 , 176 , 177 , 178 , 179 , 180 , 181 , 182 |
Deshazte de las etiquetas de código auxiliar
Sé que esta es una propuesta audaz y es probable que sea controvertida, pero las etiquetas de código auxiliar no son útiles. No consiguen que la gente edite artículos de resguardo, que es su propósito declarado. Tienen una serie de aspectos negativos: a menudo permanecen en los artículos mucho tiempo después de que se han llevado a la clase inicial y superior. Entran en conflicto con las clases indicadas en los banners de las páginas de discusión, que a menudo están más actualizadas. Añaden una imagen inútil y desorden a los artículos. Es hora de empezar a pensar en eliminarlos. Para aquellas personas que puedan sentirse reticentes, tal vez debería realizarse un experimento en el que las etiquetas de código auxiliar se eliminen de un subconjunto aleatorio de artículos, luego se comparen, digamos, un año, con un subconjunto de artículos similares y se midan los niveles de (destubificación) mejoras. ¿Alguna idea? Abductivo ( razonamiento ) 00:35, 21 de junio de 2020 (UTC)
- Creo que en realidad ha identificado dos problemas distintos aquí: 1) no tenemos ninguna evidencia de que las etiquetas stub estén logrando su propósito declarado, y 2) las etiquetas stub están en conflicto con las evaluaciones de WikiProject. Para el n. ° 1, creo que un experimento podría arrojar resultados interesantes. Para el n. ° 2, creo que esto sería una buena tarea de bot para eliminar las etiquetas de código auxiliar cuando una evaluación de WikiProject se actualiza desde el código auxiliar. Podría valer la pena actualizar {{ WPBannerMeta }} para generar un indicador de reevaluación para que el bot lo agregue cuando se elimine una etiqueta de código auxiliar, pero un WikiProject todavía lo tiene evaluado como código auxiliar. Para el experimento en el n. ° 1, sugeriría:
- Obtenga una lista de alrededor de 10,000 artículos aleatorios y elimine los que no hayan sido evaluados como un código auxiliar de WikiProjects, o que no tengan una etiqueta de código auxiliar ni un banner de WikiProject en su página de discusión.
- Haga una evaluación de los artículos restantes y elimine los que no sean en realidad resguardos.
- Divida los artículos reclamados de WikiProject por etiquetados como stub o no, y elimine / agregue etiquetas stub para que el recuento de cada artículo de WikiProject sea aproximadamente uniforme (dispare al menos 1/3 de cada uno). Elimine las etiquetas de resguardo de los artículos no reclamados para igualar el recuento total, de nuevo no menos de 1/3 para cada grupo.
- Para los dos grupos, elimine la parte superior e inferior (¿cuartil? ¿⅒th?) En términos de tamaño de edición, ignorando las ediciones del bot, y compare los dos grupos por interés (número de ediciones de editores únicos), participación (número de no revertir , ediciones no patrulladas por editores registrados) y cambio general del artículo (prosa total agregada al artículo durante el tiempo de ejecución del experimento). Van Isaac WS cont 14:17, 21 de junio de 2020 (UTC)
- Gracias por tu contribución. Abductivo ( razonamiento ) 23:07, 21 de junio de 2020 (UTC)
- Oponerse El OP no presenta ninguna evidencia para apoyar la propuesta. Yo prefiero eliminar las plantillas de proyectos y las evaluaciones, ya que nunca he visto que estas funcionen bien y tienden a quedarse más tiempo. Las plantillas de código auxiliar son comparativamente discretas y tienen un tono alentador y agradable. Andrew 🐉 ( charla ) 22:47, 21 de junio de 2020 (UTC)
- Entonces, no presento evidencia, entonces usted dice que las evaluaciones de la página de discusión no sirven de nada y tampoco presentan evidencia. Abductivo ( razonamiento ) 23:07, 21 de junio de 2020 (UTC)
- Esta no es mi propuesta y, por lo tanto, no es mi responsabilidad proporcionar pruebas. Pero aquí hay un par de ejemplos, ambos son artículos que creé recientemente. En primer lugar, considere Ambarnaya . Creé esto con la etiqueta {{ river-stub }}. Usuario: Catan0nymous agregó dos etiquetas de código auxiliar más: {{ Rusia-stub }}, {{ Siberia-stub }} y usuario: Abune luego consolidó los códigos auxiliares en {{ Rusia-river-stub }} y {{ Siberia-stub }} . Estas etiquetas parecen tener tres funciones:
- Colocando el artículo en las categorías: Categoría: Talones de geografía de Siberia y Categoría: Talones de río de Rusia
- Visualización de algunos iconos apropiados: mapas de Rusia y Siberia
- Aconsejar al lector que el artículo es solo un comienzo e invitarlo a ayudar a expandirlo
- Mi segundo ejemplo es la Lista de programas de radio de mayor duración . En ese caso, comencé con la etiqueta {{ en construcción }} porque la página necesitaba una buena estructura como base y no estaba seguro de qué sería lo mejor. Una vez hecho esto, quité la etiqueta. En ese momento, se estableció la estructura de la lista y utilicé la etiqueta {{ lista dinámica }} para indicar que la lista era bastante abierta. Esa etiqueta también invita al lector a agregar entradas de origen, por lo que tampoco vi la necesidad de una etiqueta de código auxiliar.
- Ninguno de estos casos indica que las etiquetas de código auxiliar sean un problema que deba solucionarse. Los editores sensatos los usan como mejor les parezca y no parecen causar ningún problema. Una característica que ayuda es que, por convención, se colocan al pie de un artículo, donde no estorban.
- Andrew 🐉 ( charla ) 08:00, 22 de junio de 2020 (UTC)
- Esta no es mi propuesta y, por lo tanto, no es mi responsabilidad proporcionar pruebas. Pero aquí hay un par de ejemplos, ambos son artículos que creé recientemente. En primer lugar, considere Ambarnaya . Creé esto con la etiqueta {{ river-stub }}. Usuario: Catan0nymous agregó dos etiquetas de código auxiliar más: {{ Rusia-stub }}, {{ Siberia-stub }} y usuario: Abune luego consolidó los códigos auxiliares en {{ Rusia-river-stub }} y {{ Siberia-stub }} . Estas etiquetas parecen tener tres funciones:
- Andrew Davidson , estoy de acuerdo con el sistema de evaluación. Es absurdo. Los artículos pueden ser Stub, Start, C, B, GA, A o FA. Son siete niveles, lo cual es absurdo. Las gradaciones son demasiado pequeñas y los criterios de evaluación, demasiado subjetivos. Los artículos de clase A son "muy útiles para los lectores", pero GA son "útiles para casi todos los lectores". Eso es absurdo. - RoySmith
(charla) 02:15, 22 de junio de 2020 (UTC)
- El estándar mínimo aceptable para un artículo en la página principal en ITN, OTD o DYK es efectivamente clase B debido al requisito de que estén completamente referenciados (lo mismo ocurre con los de-stubatones), aunque no podemos afirmar eso explícitamente porque Las calificaciones de clase B están en manos de los proyectos. GA y FA son evaluaciones de la comunidad. Los artículos de clase B generalmente pueden convertirse en GA, pero hay pocos incentivos para enviarlos para su revisión (GA ya está lo suficientemente retrasado), a menos que desee llevarlo a DYK, FA o FT. De manera similar, los artículos de la clase A generalmente pueden convertirse en FA después de una revisión, pero la mayoría no puede porque cada editor tiene un número limitado de envíos. Así que tenemos tres categorías (stub, start y C) para artículos de mala calidad. Las diferencias entre ellos son bastante objetivas, pero el valor de la distinción es cuestionable. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- Entonces, no presento evidencia, entonces usted dice que las evaluaciones de la página de discusión no sirven de nada y tampoco presentan evidencia. Abductivo ( razonamiento ) 23:07, 21 de junio de 2020 (UTC)
- Comentario Dudo francamente que el experimento sugerido produzca resultados claros. Las personas a menudo se muestran reacias a eliminar las etiquetas de código auxiliar o simplemente no las notan. Las etiquetas de wikiproject son tan propensas a subestimar como las del artículo en mi experiencia. Lo que podría ser más útil es una lista de artículos etiquetados como talones donde el artículo tiene un tamaño determinado (no estoy seguro de qué). Al revisar estos, esperaría que se pueda eliminar la mayoría. Por supuesto, la gente todavía tiene que hacer esto. Johnbod ( charla ) 23:59, 21 de junio de 2020 (UTC)
- El problema no es tanto elegir el tamaño determinado, sino definir qué tamaño es . La salida más fácil es contar los caracteres del wikitexto, y terminas con quarry: query / 46032 . Pero muchos de ellos solo tienen media docena o menos de oraciones, a pesar de su longitud absoluta. - Críptico 01:22, 22 de junio de 2020 (UTC)
- Como Negombo_Polling_Division , pero tiene mesas enormes, sin duda como los otros distritos electorales de Sri Lanka, y ciertamente no es un resguardo. De hecho, estoy bastante seguro de que la mayoría de estos son principalmente tablas. Pero gracias. Johnbod ( charla ) 02:44, 22 de junio de 2020 (UTC)
- ¿Conoce alguna utilidad para consultar el tamaño del texto en prosa? Van Isaac WS cont 02:06, 22 de junio de 2020 (UTC)
- https://www.mediawiki.org/wiki/ORES
articlequality
no está nada mal. Creo que adivina basándose en el descuento de palabras comunes y palabras repetidas, que a menudo es una característica de las listas y tablas. Abductivo ( razonamiento ) 04:07, 22 de junio de 2020 (UTC)- No estoy seguro de cómo funciona, pero el Proyecto MilHist lo ha estado utilizando con considerable éxito durante los últimos meses para evaluar artículos no evaluados o evaluados de forma incompleta. Los artículos que se evalúan automáticamente como clase B se marcan para revisión humana. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- WPMED lo ha estado usando con éxito, y algunos de los trabajos de ORES 'stub or not-stub' se capacitaron en artículos relacionados con la medicina. Ver m: Investigación: Selección de artículos de Medicina de WikiProject para la calidad de una consulta que me ejecutaron un par de veces. Me sentiría perfectamente cómodo teniendo un bot basado en ORES que establezca (y elimine) todas las clasificaciones de clase stub para WPMED. WhatamIdoing ( charla ) 00:34, 7 de agosto de 2020 (UTC)
- No estoy seguro de cómo funciona, pero el Proyecto MilHist lo ha estado utilizando con considerable éxito durante los últimos meses para evaluar artículos no evaluados o evaluados de forma incompleta. Los artículos que se evalúan automáticamente como clase B se marcan para revisión humana. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- https://www.mediawiki.org/wiki/ORES
- El problema no es tanto elegir el tamaño determinado, sino definir qué tamaño es . La salida más fácil es contar los caracteres del wikitexto, y terminas con quarry: query / 46032 . Pero muchos de ellos solo tienen media docena o menos de oraciones, a pesar de su longitud absoluta. - Críptico 01:22, 22 de junio de 2020 (UTC)
Teniendo en cuenta que he realizado concursos con más de 1000 artículos eliminados directamente de categorías de stub como WP: The African Destubathon y Wikipedia: The Great Britain / Ireland Destubathon y estoy ejecutando Wikipedia: The 50,000 Challenge que se alimenta directamente de las etiquetas de stub, este es uno de los más tontos. , propuestas mas ignorantes que he visto desde hace tiempo y eso es decir algo !! Existe un problema con la actualización de las etiquetas del proyecto una vez que un artículo ya no es un código auxiliar y las etiquetas auxiliares permanecen en los artículos, no en los códigos auxiliares, pero esa no es una razón para deshacerse de ellos por completo. Rosiestep y yo propusimos un bot para solucionar eso, pero la comunidad de Wikipedia, como está dividida, no nos daría el consenso que necesitamos para solucionarlo. † Encyclopædius 08:19, 22 de junio de 2020 (UTC)
- No veo por qué, Usuario: Encyclopædius . Gané algún tipo de premio en uno de sus excelentes concursos, pero cuando buscaba artículos para mejorar, recuerdo que solo quité la etiqueta de talón en aproximadamente cinco por cada uno que en realidad era un talón. No estoy de acuerdo con la abolición total, pero están en un lío serio y deberían solucionarse. Johnbod ( charla ) 13:58, 22 de junio de 2020 (UTC)
- Sí, ¿y pueden creer cuando propuse un bot para controlar la inconsistencia y eliminar las etiquetas de código auxiliar de los artículos con más de 1,5 kb de prosa legible y actualizar las etiquetas de la página de discusión a las que algunas personas se opusieron? Andrew Davidson para empezar. † Encyclopædius 14:04, 22 de junio de 2020 (UTC)
- ¿Puede un bot al menos dar la vuelta y eliminar las etiquetas de código auxiliar de todos los artículos realmente grandes que tienen plantillas de página de discusión que reclaman Start-class o superior? Entonces, ¿tal vez trabajar su camino hacia artículos más pequeños hasta que esté a punto de cometer errores? Abductivo ( razonamiento ) 04:18, 24 de junio de 2020 (UTC)
- Si. De hecho, MilHistBot ya es capaz de realizar esta tarea. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- AWB también hace algo similar al eliminar las etiquetas de código auxiliar de los artículos que superan un tamaño (generoso). WhatamIdoing ( charla ) 00:35, 7 de agosto de 2020 (UTC)
- Si. De hecho, MilHistBot ya es capaz de realizar esta tarea. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- ¿Puede un bot al menos dar la vuelta y eliminar las etiquetas de código auxiliar de todos los artículos realmente grandes que tienen plantillas de página de discusión que reclaman Start-class o superior? Entonces, ¿tal vez trabajar su camino hacia artículos más pequeños hasta que esté a punto de cometer errores? Abductivo ( razonamiento ) 04:18, 24 de junio de 2020 (UTC)
- Sí, ¿y pueden creer cuando propuse un bot para controlar la inconsistencia y eliminar las etiquetas de código auxiliar de los artículos con más de 1,5 kb de prosa legible y actualizar las etiquetas de la página de discusión a las que algunas personas se opusieron? Andrew Davidson para empezar. † Encyclopædius 14:04, 22 de junio de 2020 (UTC)
- Los "stubs" ayudan a navegar por los artículos que necesitan atención. Por lo general, se encuentran en la parte inferior del artículo y no interfieren con el lector habitual que no tiene la intención de mejorar el artículo. Básicamente, no hay nada de malo con los "talones" en lo que a mí respecta. Usuario: Abune ( charla ) 13:04, 22 de junio de 2020 (UTC)
- Muy cierto, Usuario: Abune . Los lectores rara vez los notan, e incluso si lo hacen, es difícil ver que tengan algún impacto negativo. Algunos editores los encuentran útiles. ¿Cuál es el problema? (A: no hay uno). Edwardx ( charla ) 14:34, 22 de junio de 2020 (UTC)
- Soporte calificado . En general, estoy de acuerdo con las cuestiones planteadas por el proponente. Las etiquetas de talón no son particularmente agradables desde el punto de vista estético y tienden a quedarse después de que el artículo se ha expandido hasta el punto en que ya no son apropiadas. Los esfuerzos para encontrarlos y eliminarlos en ese momento se convierten en un trabajo pesado. Me pregunto si hay algo de magia de plantilla que se pueda aplicar para que las etiquetas de código auxiliar en artículos que probablemente no sean códigos auxiliares puedan volverse invisibles y simplemente aparecer como categorías. BD2412 T 15:11, 22 de junio de 2020 (UTC)
- @ BD2412 : no hay problema: magia de plantilla . 10000 podría ser un poco demasiado. Además, tendría que hacer que todas las plantillas de código auxiliar pasen el
forcestub
parámetro para poder forzar la plantilla de código auxiliar en artículos de más de 10000 bytes. - Alexis Jazz 01:16, 21 de julio de 2020 (UTC)
- @ BD2412 : no hay problema: magia de plantilla . 10000 podría ser un poco demasiado. Además, tendría que hacer que todas las plantillas de código auxiliar pasen el
- Solución más sencilla: si encuentra un artículo que cree que ya no es un talón ... elimine la etiqueta. Problema resuelto. Blueboar ( charla ) 15:19, 22 de junio de 2020 (UTC)
- En realidad, no, prácticamente nadie que sepa cómo hacer esto mira estos artículos, todos xxx, xxx (¿cuál es el número, alguien lo sabe?). Johnbod ( charla ) 21:44, 22 de junio de 2020 (UTC)
- Hay 3.399.601 talones a partir de ahora. Puedes ver las estadísticas aquí . TryKid [ dudoso - discutir ] 23:28, 22 de junio de 2020 (UTC)
- ¡Ay! Más de la mitad de nuestros artículos. Sin embargo, estas son calificaciones de proyectos. ¡Veo 4.310 códigos auxiliares de "máxima importancia"! Gracias, Johnbod ( charla ) 01:28, 23 de junio de 2020 (UTC)
- Me gustaría ver uno de esos talones de máxima importancia. Para empezar, seguí el enlace de TryKid para encontrar Categoría: Stub-Class_articles . De esto, seleccioné Categoría: artículos de contabilidad de clase auxiliar porque existe un sesgo sistémico en contra de los artículos comerciales. El estándar de contabilidad parecía prometedor y descubrí que esto se evalúa como de alta importancia, pero de clase Stub. Todo esto proviene de la plantilla del proyecto, ya que la página del artículo no tiene etiquetas. Le vendría bien un poco porque noté de inmediato un aullido descarado: "Los estándares de contabilidad se escribieron en gran parte a principios del siglo XXI " . Lo que también noto es que, si bien su página de discusión solo tuvo 7 lectores en los últimos 30 días, el artículo en sí tuvo 2,481 . Ahora podría etiquetar el artículo, pero lo que realmente necesita es una mejora ... Andrew 🐉 ( charla ) 08:55, 23 de junio de 2020 (UTC)
- Sí, talones de calificación de proyectos de 3M. El número de stubs "etiquetados" parece ser 2,265,086, de Categoría: Todos los artículos stub . Este número parece más correcto ya que muchos de los "stubs de mayor importancia" ya no son stubs y ya están separados, pero la página de discusión no se actualizó. Como se señaló anteriormente, incluso muchos de los códigos auxiliares "etiquetados" no son códigos auxiliares. Tal vez se necesite un bot que actualice automáticamente la calificación del proyecto de los stubs a "iniciar" si no se encuentra una etiqueta en la página principal. La idea de Blofeld de separar automáticamente si el artículo está por encima de cierto tamaño también fue buena. TryKid [ dudoso - discutir ] 12:59, 23 de junio de 2020 (UTC)
- ¡Ay! Más de la mitad de nuestros artículos. Sin embargo, estas son calificaciones de proyectos. ¡Veo 4.310 códigos auxiliares de "máxima importancia"! Gracias, Johnbod ( charla ) 01:28, 23 de junio de 2020 (UTC)
- Hay 3.399.601 talones a partir de ahora. Puedes ver las estadísticas aquí . TryKid [ dudoso - discutir ] 23:28, 22 de junio de 2020 (UTC)
- En realidad, no, prácticamente nadie que sepa cómo hacer esto mira estos artículos, todos xxx, xxx (¿cuál es el número, alguien lo sabe?). Johnbod ( charla ) 21:44, 22 de junio de 2020 (UTC)
- Soporte En mis primeros días (2005), la clasificación de stub era uno de mis pasatiempos favoritos, y me entristece finalmente desaprobar las plantillas de stub, pero hoy en día son una duplicación de las plantillas de evaluación en la página de discusión y, por lo tanto, son innecesarias. - Rey de ♥ ♦ ♣ ♠ 01:58, 23 de junio de 2020 (UTC)
- Oponerse , aunque una posible alternativa es vincular las etiquetas de código auxiliar al banner de WikiProject, si el artículo se evalúa como una clase de código auxiliar, un bot agrega la etiqueta, si (con suerte cuando) el artículo se actualiza a Inicio o superior, un bot elimina la etiqueta. . Cavalryman ( hablar ) 02:19, 23 de junio de 2020 (UTC). Comentario enmendado para oponerse a la retención de suplente. Cavalryman ( hablar ) 06:55, 27 de julio de 2020 (UTC).
- Esta es una muy buena idea . Soluciona la discrepancia entre la página principal y la charla, mientras mantiene un cierto nivel de aliento amistoso en la página principal. - Nabla ( charla ) 14:52, 27 de junio de 2020 (UTC)
- Oponerse Si bien estoy de acuerdo en que muchos de los problemas que enumeró son reales y afectan a Wikipedia, las etiquetas stub son necesarias. Puede que no sean muy efectivos para lograr que los lectores / editores agreguen contenido o eliminen la publicación de los artículos, pero hacen un contraste vital entre lo que es y lo que no es una extensión razonable para un artículo enciclopédico. A la mayoría de los lectores no les interesa navegar por la miríada de páginas informativas de Wikipedia sobre la extensión del artículo, las diferentes clases, la prosa, etc. Las etiquetas stub son simples, fáciles de entender y van al grano. Si vamos a deshacernos de las etiquetas de código auxiliar, ¿por qué no eliminar la clasificación de código auxiliar por completo? No tiene sentido. Deben realizarse mejoras, pero las necesitamos. Su importancia para el proyecto anula cualquier aspecto negativo. MrSwagger21 ( charla ) 02:26, 23 de junio de 2020 (UTC)
- Oponerse por MrSwagger21. - ZLEA T \ C 02:52, 23 de junio de 2020 (UTC)
- Comente sobre el equilibrio entre las necesidades del editor y el lector . Con respecto a las necesidades de los editores (que siempre tendemos a priorizar en exceso, dado el sesgo sistémico introducido por quiénes somos), mi conclusión aquí es que parece que no hay evidencia de que las etiquetas atraigan a los editores, y aunque es perfectamente plausible que lo hagan, esto podría ser un problema. es bueno que alguien haga un estudio de investigación. Con respecto a las necesidades del lector (que no veo que realmente reciba la atención adecuada aquí), la forma en que indicamos la calidad del artículo es un poco peculiar: indicamos GA / FA con un tema, pero talones con una etiqueta en la parte inferior y nada en el medio. . Creo que es razonable argumentar que los códigos auxiliares, dada su baja calidad, deberían tener las etiquetas como una especie de advertencia. El contraargumento sería WP: NODISCLAIMERS y el hecho de que hay una distinción entre baja calidad y poco tiempo, y la mayoría de los stubs en mi experiencia anecdótica no son de menor calidad que las páginas de clase inicial / C, solo más cortos. No estoy seguro de dónde llego a la necesidad de las etiquetas stub, pero espero que consideremos cómo afectan la experiencia de los lectores que no editan, no solo de los editores. Ya mencioné antes que hay margen de mejora en la forma en que presentamos las evaluaciones de contenido a los lectores de manera más general (en particular, la diferencia entre GA y FA no está clara), y me gustaría ver más trabajo en esa área. {{u | Sdkb }} charla 07:53, 23 de junio de 2020 (UTC)
- Oponerse no. Son útiles y discretos. No de la manera de nadie. Saludos, GenQuest "Talk to Me" 10:47, 23 de junio de 2020 (UTC)
- Comentario : perdón por la autopromoción, pero esto es algo que se podría hacer con relativamente poca consternación si mi propuesta para una extensión que agrega categorías de etiquetas en la página de discusión tuvo éxito. Tal movimiento permitiría que las páginas retengan las categorías de código auxiliar, sin la duplicación de esfuerzos para etiquetar el artículo con etiquetas de código auxiliar y también realizar las evaluaciones en la página de discusión. Naypta ☺ | ✉ página de discusión | 13:07, 23 de junio de 2020 (UTC)
- débil se opone por ahora - Las personas con las que hablo (no editores) a menudo no saben que existe una página de discusión para un artículo. Si una etiqueta de código auxiliar anima a una persona ocasional a agregar contenido, lo veo como algo bueno. Si hubiera alguna forma de demostrar que no hay evidencia de que esto ocurra, entonces apoyaría su desaprobación. Debo agregar que valía la pena plantear la propuesta y que consideré apoyarla, y creo que vale la pena explorar el tema. Cas Liber ( charla · contribuciones ) 04:54, 24 de junio de 2020 (UTC)
- Soporte condicional . Las plantillas de código auxiliar son desordenadas y desactualizadas, y no hacen lo que se supone que deben hacer, aunque tienen otros usos importantes. Sugiero eliminar las plantillas, pero reemplazarlas con categorías o una función dentro de los banners de WikiProject. Reh man 05:21, 24 de junio de 2020 (UTC)
- Soporte : la simplificación es buena. Lo que hacen los stubs puede / es / debería hacerse en un banner de página de discusión, por ejemplo, evaluaciones de wikiproject. La conclusión es que deberíamos tener un lugar donde registrar en qué estado se encuentra un artículo, y ese lugar probablemente debería ser en el banner de una página de discusión. Levivich [ dudoso - discutir ] 19:26, 26 de junio de 2020 (UTC)
- Oponerse según Cas Liber. Las etiquetas de talón son, en el peor de los casos, benignas. Son el final literal del artículo y si un lector quiere ignorarlo, puede hacerlo. Realmente no puedo entender cómo pueden verse como dañinos. Por otro lado, si consiguen que 1 lector ayude a expandir un artículo, la enciclopedia se beneficia enormemente prácticamente sin costo alguno. Son una clara neta positiva. Ponerlos en la página de discusión puede ser conveniente para nosotros y para nuestras categorizaciones internas, pero eso es contraproducente para la mejora del artículo. La mayoría de las personas no conocen las páginas de discusión (en serio, pregúntales a tus amigos la última vez que vieron una página de discusión de un artículo), por lo que ocultar las etiquetas de código auxiliar donde solo las personas con información privilegiada las encontrarán es, en mi opinión, una neta negativa. - Wug · a · po · des 21:37, 27 de junio de 2020 (UTC)
- Oponerse . Las plantillas de código auxiliar son un tipo de plantilla de mantenimiento. Debido a su ubicuidad, hemos decidido ponerlos al final de la página en lugar de hacerlo en la parte superior. Comparten todos los pros y contras de otras plantillas de mantenimiento. Por un lado, creemos que, dada la naturaleza dinámica de Wikipedia, deberíamos alertar a los lectores y editores si algo no va bien con un artículo. Por otro lado, no sabemos si se dedica más tiempo a etiquetar o corregir artículos. El principal problema que veo con las plantillas de código auxiliar es lo que otros han señalado anteriormente. Tenemos dos sistemas para marcar un artículo como un código auxiliar: plantillas de código auxiliar y banners de páginas de discusión. Estos no siempre están sincronizados. Cuando esto sucede, la culpa es del editor que (des) aprueba un artículo utilizando un solo método. La directriz en WP: DESTUB dice hacerlo usando ambos. Estoy seguro de que estamos avanzando hacia la evaluación automática de artículos ( WP: ORES ) a cierto ritmo. Mientras tanto, deberíamos automatizar la eliminación de las discrepancias entre las plantillas de código auxiliar y las evaluaciones de la página de discusión mediante un bot. - Finnusertop ( charla ⋅ contribuciones ) 23:20, 27 de junio de 2020 (UTC)
- "No sabemos si se dedica más tiempo a etiquetar o corregir artículos" Probablemente el primero, en mi opinión. RandomCanadian ( charla / contribuciones ) 03:43, 5 de julio de 2020 (UTC)
Soporte Una buena solución, como ya han propuesto otros, sería la categorización a través de banners de wikiproject en la página de discusión. RandomCanadian ( charla / contribuciones ) 03:43, 5 de julio de 2020 (UTC)Marioneta llamativa. P-K3 ( conversación ) 22:47, 8 de julio de 2020 (UTC)- Oponerse a que no estoy bromeando al decir que normalmente así es como encuentro GA para escribir. Las etiquetas de código auxiliar son invaluables. TonyBallioni ( charla ) 02:17, 6 de julio de 2020 (UTC)
- Me opongo a que odio crear artículos (por alguna razón), no creo que haya creado un artículo todavía. Ayudo a mejorar enormemente los artículos existentes y tengo planes de editar un par de artículos de resguardo y hacerlos más completos. Los stubs tienen sus beneficios, ayudan a encontrar temas que pueden parecer interesantes y dan la oportunidad de expandirlos. Además, lo que dijo Tony anteriormente. ProcrastinationReader ( charla ) 12:23, 6 de julio de 2020 (UTC)
- Comentarios : inclinarme hacia la oposición, ya que la ubicación de WikiProject en las páginas de Talk las hace menos obvias para los lectores y editores, hasta el punto de que tiendo a olvidarme de ellas. También me interesaría saber:
- ¿Todas las categorías de stub tienen WikiProjects asociados?
- ¿Existe una manera fácil de obtener una lista de páginas de artículos (a diferencia de las páginas de discusión; cf Categoría: artículos de videojuegos Stub-Class a Categoría: talones de videojuegos ) de las categorías de WikiProject?
- ¿Se podrían organizar los stubs de WikiProject en subcategorías como las plantillas de stub?
- - Ost ( conversación ) 22:27, 9 de julio de 2020 (UTC)
- Soporte condicional débil . Según @ Rehman arriba. Sin embargo, pocos editores pueden seguir usando esas plantillas de código auxiliar. Si estuvieran en la cima, tal vez sería diferente, pero yo digo que los dejes caer y sigas lo que Rehman dijo anteriormente. - Guitarist28 ( charla ) 14:32, 14 de julio de 2020 (UTC)
- Oponerse a la eliminación. Sin embargo, creo que debería cambiarse el formato de la etiqueta. Vengo desde la perspectiva de un wikiHowian, donde las etiquetas de código auxiliar se colocan encima de los artículos de código auxiliar. Creo que sería más útil si la etiqueta de código auxiliar tuviera la forma de otras plantillas de mantenimiento. Algo como:
De esa forma, los lectores ven lo que pueden hacer para ayudar a Wikipedia. Al tenerlos en la parte superior, los lectores pueden trabajar para expandir el artículo y luego eliminar la etiqueta de talón una vez que el artículo brinde más cobertura. A a s i m 08:06, 18 de julio de 2020 (UTC)- Awesome Aasim , me gusta la idea de una etiqueta más clara, aunque debería ser ambiguo que no sea un problema importante con el artículo en sí, y debería animar a las personas a crear la página, como:
Ed 6767 hablar! 00:21 21 de julio de 2020 (UTC)
- Awesome Aasim , me gusta la idea de una etiqueta más clara, aunque debería ser ambiguo que no sea un problema importante con el artículo en sí, y debería animar a las personas a crear la página, como:
- Comentario Un paso muy necesario sería revisar todos estos stubs y verificar que sean, de hecho, stubs. En mi propia búsqueda de artículos, descubrí que una cuarta parte debería volver a calificarse como "Inicio" o mejor. Y aproximadamente 1 de cada 10 de la clase "Inicio" debería volver a clasificarse como "C" o mejor. (Dado que mi experiencia está en desacuerdo con Johnbod anterior, ¿tal vez mi evaluación es más estricta que la suya?) En cualquier caso, creo que reevaluar tantos códigos como sea posible ayudaría a reducir el número de códigos en Wikipedia a menos de la mitad del total. número. - llywrch ( charla ) 21:52, 20 de julio de 2020 (UTC)
- Hay dos tipos de artículos aquí: (1) artículos que ya se han vuelto a calificar como iniciales o superiores, pero que aún tienen plantillas de mensajes de Categoría: Stub ; y (2) artículos que están clasificados como stubs, pero que en realidad son de inicio o superior. Hawkeye7 (discutir) 22:57, 20 de julio de 2020 (UTC)
- Posiblemente, o estamos viendo diferentes artículos. Creo que la mayoría de los evaluadores solo tienen en cuenta la longitud, mientras que para algunas materias, unas pocas líneas pueden ser C o incluso más. Las definiciones oficiales de las clases son bastante generosas y creo que la mayoría de los evaluadores son demasiado estrictos (además de juzgar principalmente por la duración). Johnbod ( charla ) 00:08, 21 de julio de 2020 (UTC)
- Responder a ambos comentarios juntos. Hawkeye7, el primer caso podría abordarse fácilmente con un bot, y probablemente deba hacerse en cualquier caso, mientras que el segundo describe el fenómeno del que estaba hablando. Johnbod , sospecho que podríamos estar viendo diferentes artículos o grupos de artículos. Cuando llamo a un artículo un "trozo", me fijo más en cuán completamente el artículo cubre el tema que en la extensión: hay algunos personajes históricos notables sobre los cuales todo lo que podemos escribir está limitado a 2 o 3 oraciones, lo que significa que estamos estancados con lo que llamo "permastub", aunque si un artículo tiene, digamos, 5.000 bytes de tamaño y está marcado como "stub", voy a analizar detenidamente por qué tiene esa evaluación en lugar de un "inicio" o Clase "C". Y a veces se requiere conocimiento experto para saber qué información está disponible sobre un tema determinado, para saber si el artículo lo cubre por completo. - llywrch ( charla ) 16:55, 21 de julio de 2020 (UTC)
- Ah, quizás estándares diferentes entonces - estoy con User: Grutness / Croughton-London regla de stubs , y de hecho la definición oficial , aunque por supuesto "la amplitud de cobertura que se espera de una enciclopedia" (de la que carecen los stubs) es maravillosamente vaga. Pero la mayoría de los artículos en la mayoría de las enciclopedias impresas serían llamados "talones" por la mayoría de los asesores de WP imo. Johnbod ( charla ) 17:23, 21 de julio de 2020 (UTC)
- Responder a ambos comentarios juntos. Hawkeye7, el primer caso podría abordarse fácilmente con un bot, y probablemente deba hacerse en cualquier caso, mientras que el segundo describe el fenómeno del que estaba hablando. Johnbod , sospecho que podríamos estar viendo diferentes artículos o grupos de artículos. Cuando llamo a un artículo un "trozo", me fijo más en cuán completamente el artículo cubre el tema que en la extensión: hay algunos personajes históricos notables sobre los cuales todo lo que podemos escribir está limitado a 2 o 3 oraciones, lo que significa que estamos estancados con lo que llamo "permastub", aunque si un artículo tiene, digamos, 5.000 bytes de tamaño y está marcado como "stub", voy a analizar detenidamente por qué tiene esa evaluación en lugar de un "inicio" o Clase "C". Y a veces se requiere conocimiento experto para saber qué información está disponible sobre un tema determinado, para saber si el artículo lo cubre por completo. - llywrch ( charla ) 16:55, 21 de julio de 2020 (UTC)
- Si bien apoyo la idea, hay algunas cosas que debemos considerar:
- El público. Stub llegó a tener significado fuera de la comunidad de editores: la lista que cambia gradualmente de color en la pantalla de Haskell representaba a cientos de mujeres científicas que nunca habían tenido una entrada en Wikipedia, o cuyas vidas y trabajos se descartan en un fragmento de unas pocas líneas.
- Preferiría algo más descriptivo, como {{La televisión necesita sección de producción }}. El etiquetado de stub es un poco flojo. (culpable de los cargos)
- Apoyo mucho un experimento. Sugeriría que escojamos varios artículos. Para la mitad de ellos se crea un hash y solo se publica el hash. Para la otra mitad, elimina u oculta la etiqueta de código auxiliar, pero no publica una lista. Claro que uno podría ver las contribuciones del bot que lo hace, pero no podemos controlar eso. Tendremos que esperar hasta que se haya mejorado una cantidad decente de artículos en la lista más allá del estado de stub, momento en el que publicaremos la lista de artículos todavía con stub y comparar.
- Como sugirió BD2412, Template magic . - Alexis Jazz 01:16, 21 de julio de 2020 (UTC)
- Oponerse a los editores en College Football Project a menudo usan la etiqueta stub para enfocar los esfuerzos de edición y ayudar a mejorar los artículos .-- Paul McDonald ( charla ) 13:20, 24 de julio de 2020 (UTC)
- Oponerse a eliminar las plantillas de código auxiliar, tienen una función. Posiblemente también necesitemos:
- agregar una opción para notas a la plantilla de talón
- explorar una forma de fusionar el marcado de stub y los sistemas de evaluación
- Cree una tarea de bot para encontrar artículos de resguardo que hayan crecido / hayan tenido n ediciones / hayan tenido un cambio de evaluación. - GhostInTheMachine me habla a las 13:05, 27 de julio de 2020 (UTC)
- Comentario : he editado cientos de artículos de código auxiliar de música, principalmente agregándoles RS. Encuentro que los talones son útiles para clasificar, al menos en este aspecto específico. Caro7200 ( charla ) 15:55, 29 de julio de 2020 (UTC)
- Soporte para repensar completamente qué son las etiquetas stub y qué se supone que deben lograr, y si lo hacen. En mi opinión, hay tres cosas que estamos tratando de lograr: (i) decirle a la gente que el artículo no está completo (ii) pedirles que contribuyan y (iii) ordenar las etiquetas de código auxiliar para que la gente pueda concentrarse en los códigos auxiliares. en un área que les interese. El punto (i) es obvio sin la etiqueta, pero a menudo permanece en el artículo mucho después de que deja de ser útil. Dado el tiempo que algunos artículos permanecen como resguardos, obviamente no estamos haciendo un gran trabajo con (ii). La clasificación de stub ha sido parcialmente reemplazada por el etiquetado de wikiproject y un sistema de categorías generalmente mucho mejor. Debo admitir que me gusta el hecho de que los clasificadores de resguardos estén ahí (etiquetar un artículo como "resguardo" es una forma rápida de obtener un par de ojos extra, ya que invoca un clasificador de resguardos en unas pocas horas como máximo). Pero no he visto ninguna evidencia reciente de que etiquetar y categorizar stubs en realidad conduzca a una gran mejora, o que la duplicación de etiquetado de stub / no stub en el artículo más la página de discusión haga algo útil. Tener una manera fácil de mostrar la calidad del artículo (no solo el estado del código auxiliar / no el código auxiliar) en cualquier categoría o para cualquier enlace en una lista sería mucho más útil. No solo es necesario mejorar los talones. - Kusma ( t · c ) 22:47, 1 de agosto de 2020 (UTC)
- Comentario Me parece interesante que nadie haya mencionado la clasificación de Wikipedia: WikiProject Stub , cuyos miembros podrían tener algo que contribuir a esta discusión (tampoco reconozco a ninguno de los comentaristas aquí del proyecto). Uno de nuestros miembros aparentemente encontró esta discusión ayer (1 de agosto) y publicó una nota en la página de discusión de WPSS. Pondré mi 2p más tarde cuando tenga la oportunidad de leer todas las entradas aquí. Saludos, su nave de clavija ( ? ) 20:32, 2 de agosto de 2020 (UTC)
- Oponerse : Personalmente marco varias categorías de código auxiliar relevantes para mis intereses y las amplío periódicamente, contradiciendo la afirmación de que las etiquetas de código auxiliar "no hacen que la gente edite artículos de código auxiliar". Creo que el único problema real aquí son los artículos que ya no son resguardos y siguen estando etiquetados como tales. A veces, no estoy seguro de cuándo estoy mejorando los artículos de forma muy gradual y en qué punto han dejado de ser stubs. Apoyaría a un bot para eliminar las etiquetas de código auxiliar obsoletas en función de las evaluaciones de la página de discusión o en una barrera de longitud más allá de la cual un artículo claramente no es un código auxiliar. ~ oulfis 🌸 ( hablar ) 01:11, 3 de agosto de 2020 (UTC)
- Los talones de soporte son desordenados y el desorden visual es inmenso para el lector. Epelerenon ( charla ) 05:25, 3 de agosto de 2020 (UTC)
- Soporte Las etiquetas auxiliares son una reliquia de una era anterior. Ahora que todos los artículos obtienen calificaciones de calidad de varios proyectos en la página de discusión, es redundante tenerlos también anotados como resguardos en la página principal del artículo. El tiempo que se invierte en agregar etiquetas y encontrar las categorías adecuadas, y luego en eliminarlas, es una pérdida de tiempo. CaptainEek edita Ho Cap'n! ⚓ 06:57, 3 de agosto de 2020 (UTC)
- Oponerse . Si bien los WikiProjects cubren muchos temas, no todos los artículos de resguardo entran dentro del ámbito de un WikiProject, y no todos los proyectos utilizan etiquetas de evaluación. No tengo ninguna opinión sobre las etiquetas de evaluación de proyectos, pero las etiquetas / tipos / gatos de código auxiliar no solo son aplicables y útiles en toda la enciclopedia, sino que también son una forma de evaluar qué temas necesitan mantenimiento de otro tipo. (Creo que los parámetros de lo que constituye un artículo de código auxiliar deben revisarse.) Por último, pero ciertamente no menos importante, los editores de Wikipedia: La clasificación de código auxiliar de WikiProject han mantenido, ordenado y estandarizado fielmente los tipos de código auxiliar durante más de 15 años (que yo saber), y eliminar los frutos de ese trabajo en la enciclopedia sería contraproducente. Su Pegship ( ? ) 17:36, 3 de agosto de 2020 (UTC)
- Oponerse : con frecuencia me disgustan las etiquetas y el bombardeo de etiquetas. Pero considero que las etiquetas de código auxiliar son las menos intrusivas y una de las más valiosas de todas las etiquetas. Los trabajos de bot de actualizar el artículo o la página de discusión cuando se cambia uno sería valioso, pero las etiquetas ayudan a los editores a encontrar códigos auxiliares en una categoría que les interesa. Las categorías de códigos auxiliares y WikiProjects no se alinean del todo, como yo ' No soy el primero en señalarlo, y creo que esta es una característica, no un error. - Bilorv ( conversación ) 23:13, 3 de agosto de 2020 (UTC)
- La inconsistencia entre las etiquetas de la página del artículo y las etiquetas del proyecto de la página de discusión no es ciertamente una "característica", es puramente el resultado del descuido / descuido / ignorancia por parte de los editores. La definición de talón es general: otras calificaciones de calidad pueden variar según la relevancia de un artículo para un proyecto en particular, pero un artículo debe ser o no un talón para todos. ¿Cuál sería el beneficio de tal "característica"? Johnbod ( charla ) 01:28, 4 de agosto de 2020 (UTC)
- Creo que lo que Bilorv quiere decir con "
categorías de código auxiliar y WikiProjects no se alinean
" no es una inconsistencia entre las calificaciones en las etiquetas de código auxiliar y las evaluaciones de WikiProject (es decir, el mismo artículo se llama código auxiliar en un lugar y clase de inicio en otro, que es un "error"), pero las diferencias entre las categorías de código auxiliar y los WikiProjects existentes (es decir, un artículo etiquetado como '18thC-novel-stub' aunque no hay un wikiproject para las novelas del 18thC). Estoy de acuerdo con Bilorv en que este segundo tipo de desalineación es una característica y no un error, ya que es útil que las categorías de código auxiliar sean específicas, mientras que los wikiprojects deben ser bastante amplios. Para el Destubathon de Gran Bretaña e Irlanda , por ejemplo, fue extremadamente útil tener stubs categorizados por regiones geográficas bastante específicas, aunque sería una tontería que existiera todo un wikiproyecto de Shropshire. ~ oulfis 🌸 ( charla ) 19:51, 4 de agosto de 2020 (UTC)- Gracias Oulfis , esto es exactamente lo que quise decir y disculpas por la confusión. - Bilorv ( conversación ) 20:47, 4 de agosto de 2020 (UTC)
- Muy bien, gracias por la aclaración. Johnbod ( charla ) 21:07, 4 de agosto de 2020 (UTC)
- Gracias Oulfis , esto es exactamente lo que quise decir y disculpas por la confusión. - Bilorv ( conversación ) 20:47, 4 de agosto de 2020 (UTC)
- Creo que lo que Bilorv quiere decir con "
- La inconsistencia entre las etiquetas de la página del artículo y las etiquetas del proyecto de la página de discusión no es ciertamente una "característica", es puramente el resultado del descuido / descuido / ignorancia por parte de los editores. La definición de talón es general: otras calificaciones de calidad pueden variar según la relevancia de un artículo para un proyecto en particular, pero un artículo debe ser o no un talón para todos. ¿Cuál sería el beneficio de tal "característica"? Johnbod ( charla ) 01:28, 4 de agosto de 2020 (UTC)
- Soporte . Las etiquetas de talón son un subconjunto del sistema de calificación de proyectos (y son anteriores a los proyectos). Varias personas han declarado que utilizan las etiquetas de código auxiliar para encontrar trabajo. Eso es genial, pero podrían hacer exactamente lo mismo si marcaran las categorías de código auxiliar del proyecto aplicables, como Categoría: artículos de animales de la categoría Stub , o incluso artículos de Categoría: Stub-Class . Como tipo de software, creo en DRY , y ahora que tenemos calificaciones de proyectos, las etiquetas stub violan eso. - RoySmith (charla) 01:55, 4 de agosto de 2020 (UTC)
- La referencia a DRY está graciosamente mal dirigida. En mi experiencia, los artículos no suelen tener múltiples etiquetas de código auxiliar, pero a menudo se encuentra una gran proliferación de etiquetas de proyectos en la página de discusión. y por eso suelo usar {{ WikiProjectBannerShell }} para reducir el desorden. Por ejemplo, recientemente actualicé Stonehenge, que tiene 11 plantillas de proyectos diferentes que van desde vistas alternativas de WikiProject hasta sitios del patrimonio mundial de WikiProject , un proyecto que está explícitamente inactivo. Las diversas calificaciones de los proyectos son inconsistentes y también hay otras evaluaciones independientes, como una calificación Vital y una revisión de GA . Si desea reducir el desorden repetitivo, el lugar para comenzar es la página de discusión. ¿Por qué, por ejemplo, no hay una plantilla única para proyectos que enumere todos los proyectos relevantes en una lista combinada? ¿Por qué cada proyecto tiene que tener su propia plantilla separada? No está inventado aquí , supongo. Andrew 🐉 ( charla ) 09:59, 4 de agosto de 2020 (UTC)
- Comentario : "
todos los artículos obtienen calificaciones de calidad de varios proyectos en la página de discusión
"? No. No es así. Ordeno muchos stubs, y con frecuencia creo la página de discusión y agrego pancartas de proyectos. Muchos lectores no saben mucho sobre proyectos, no pertenecen a uno, solo editan su propio subconjunto elegido de artículos, o realizan su subconjunto favorito de Wikignoming. Si las categorías de stub fueran abolidas en la creencia de que los proyectos lo hacen todo, necesitaríamos una categoría de mantenimiento como "Páginas ( que no sean páginas dab o redireccionamientos) cuya página de discusión no tiene banner del proyecto ", e incluso entonces las páginas que tienen {{ WP Bio }} pero nada más específico terminarían perdidas. Pam D 19:02, 4 de agosto de 2020 (UTC) - Soporte : las etiquetas de código auxiliar son solo un desorden visual. Por lo general, puede obtener la misma información de las categorías de WikiProject. Mantener la misma información en varios lugares es una pérdida de tiempo y esfuerzo (y de espacio en la pantalla). Kaldari ( charla ) 20:35, 4 de agosto de 2020 (UTC)
- Soporte . Ya no es necesario. Es de suponer que tenemos muchas funciones sobrantes que ya no son necesarias, y este sería un buen comienzo para aclararlas. DGG ( charla ) 00:26, 5 de agosto de 2020 (UTC)
- Fuerte apoyo : basura inútil. Schierbecker ( charla ) 14:22, 5 de agosto de 2020 (UTC)
- Oponerse : las etiquetas de código auxiliar están fuera del camino, no interfieren con la lectura del artículo y ayudan a categorizar y llamar la atención sobre los artículos que necesitan más contenido. Eliminarlos sería contraproducente. Un mejor uso de nuestro tiempo sería un bot que elimine las etiquetas de código auxiliar de los artículos que superen un cierto tamaño de prosa. Ciridae ( charla ) 16:30, 5 de agosto de 2020 (UTC)
- Soporte . El único beneficio potencial es la facilidad de buscar artículos muy cortos para expandir, y eso ya se puede hacer con las calificaciones de Wikiproject. Mientras tanto, dudo que los lectores de 2020 necesiten más etiquetas de código auxiliar. SnowFire ( charla ) 21:39, 5 de agosto de 2020 (UTC)
- Oponerse . Las etiquetas stub están vinculadas a otras partes de la enciclopedia y funcionan con las calificaciones de Wikiproject, por lo que eliminarlas causaría un conjunto de otros problemas. Francamente, me gustan las etiquetas stub, definitivamente han animado a algunos lectores a contribuir positivamente al proyecto. En una era en la que Wikipedia está perdiendo nuevos colaboradores, ¿no deberíamos intentar atraer a más? Tampoco es que estén ocupando espacio en los servidores y no desordenan los artículos tanto como las etiquetas de problemas en la parte superior. Modificarlos parece ser una mejor manera de lograr lo que quiere el póster original. Usuario: Heyoostorm _talk! 16:26, 6 de agosto de 2020 (UTC)
- Soporte - Mi opinión es que los talones son graffitis y no sirven para nada. —¿Philoserf? ( charla ) 08:07, 8 de agosto de 2020 (UTC)
- Creo que me quedo en el oponen lado del espectro así. No creo que tenga sentido confiar en las calificaciones de WP (como se señaló anteriormente, muchas páginas terminan con etiquetas de código auxiliar pero no etiquetas de WP). Por lo que respecta a la utilidad, tiendo a estar de acuerdo en que el lado de "encontrar artículos breves que puedan usar la expansión" es bastante convincente desde el punto de vista de la utilidad y la estética. Me parece un poco desagradable que a veces estos no coincidan con las calificaciones de WP, pero eso es un trabajo para un bot (como se señaló anteriormente). Si tengo algún problema con las etiquetas de código auxiliar, es que básicamente duplican nuestra estructura de categorías (ya sea en el lado del artículo o en el lado de WP), y podrían usar un árbol mucho más pequeño para seleccionar una etiqueta de código auxiliar. (Incluso podría sugerir que deberíamos eliminar todas las etiquetas sub-stub y poner el peso en las categorías adecuadas y las etiquetas WP adecuadas; los editores interesados en stubs para las categorías de interés pueden usar una de nuestras herramientas de intersección, como WP: PetScan ). Desde una perspectiva de visibilidad, de hecho me gusta la idea de ir completamente {{ ambox }} con ellos.
En una nota tangencial, me entristece un poco que muchas de las llamadas a la acción se intenten ocultar con tanta frecuencia en la página de discusión o convertirlas en categorías ocultas. Queremos nuevos editores y tal vez la mejor manera de conseguirlos no se encuentre escondida. (No importa todas las otras formas en que el mundo ha cambiado en dos décadas, como el 60% actual de lectores en dispositivos móviles) - Izno ( charla ) 22:58, 9 de agosto de 2020 (UTC)
- Apoyo. Lectura obligatoria de la ceguera de Banner sobre por qué esas cosas son inútiles para el lector promedio. Popo le Chien lanza un hueso 18:44, 10 de agosto de 2020 (UTC)
- Oponerse a las plantillas de resguardo obsoletas. La parte visible de la plantilla es para el lector, no para los editores. Envía el mensaje de que Wikipedia no está terminada . También calma la reacción "WTH, ¿esto es todo lo que tienes sobre el tema?" diciendo "sí, sabemos que esto está incompleto". La ceguera de los banners puede aplicarse a lectores frecuentes, pero también deberíamos considerar lectores más casuales. Compare {{ User page }} y {{ User sandbox }} que también tienen como objetivo informar a los no iniciados. Aunque la llamada a la acción probablemente no resulte en una acción inmediata, refuerza la idea de "cualquiera puede editar". Pelágicos ( mensajes ) - (17:23 martes 11, AEST) 07:23, 11 de agosto de 2020 (UTC)
- Comentarios . Las plantillas de páginas de conversación se suprimen en dispositivos móviles, mientras que las etiquetas de código auxiliar no (aunque es posible que deba expandir Referencias o Enlaces externos, sea cual sea la última sección). Además, no es inmediatamente obvio que la página de discusión debería ser el lugar donde se buscan otros metadatos del artículo, como la calificación de calidad. Pelágicos ( mensajes ) - (17:23 martes 11, AEST) 07:23, 11 de agosto de 2020 (UTC)
- Preguntas . Si Encyclopædius y Rosiestep no pudieron llegar a un consenso para un bot que actualice directamente las etiquetas de código auxiliar y de calidad, ¿qué tal un bot que las agregue a una categoría para su revisión, como Categoría: códigos auxiliares sin código auxiliar ? ¿O alguna otra consulta interactiva? ¿Qué tan caro en recursos es ejecutar un artículo a través de ORES, la puntuación se calcula automáticamente al guardar / publicar y se almacena con la revisión, o sería costoso ejecutar un bot que compara las puntuaciones de ORES con etiquetas de código auxiliar? Pelágicos ( mensajes ) - (17:23 martes 11, AEST) 07:23, 11 de agosto de 2020 (UTC)
- Existe Wikipedia: Informes de base de datos / Apéndices largos , que se ha actualizado recientemente. No sé si hay un bot que puede verificar las entradas, o si solo lo puede hacer un humano. Su Pegship ( ? ) 17:36, 12 de agosto de 2020 (UTC)
- Soporte por DGG. Estoy de acuerdo en que han sobrevivido a su utilidad. También son un pozo de trabajo para los editores gnome (clasificación de códigos auxiliares) que de otra manera estarían haciendo cosas más útiles. Calliopejen1 ( charla ) 00:16, 16 de agosto de 2020 (UTC)
- Para algunos de nosotros, los gnomos, la clasificación de códigos auxiliares es el único aspecto de la edición de WP en el que nos sentimos seguros. No es una razón para mantener talones ... solo digo. ; P Her Pegship ( ? ) 00:52, 16 de agosto de 2020 (UTC)
- Soporte Hay varios artículos en Wikipedia, que son lo suficientemente largos como para no ser un artículo stub, pero aun así están clasificados como stub. Vaya a https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Long_stubs Aunque algunos artículos pequeños no se clasifican como stub, lo que reduce el valor de las etiquetas Stub. En Wikipedias menos utilizadas como la Wikipedia en hindi y la Wikipedia en bengalí, el problema es aún más pronunciado, donde la mayoría de los artículos más pequeños (algunos con menos de 100 palabras) no se clasifican como Stub, mientras que algunos artículos anteriormente Stub, que desde entonces han sido mejorado, todavía contiene las etiquetas stub. Soukarya ( charla ) 13:07, 18 de agosto de 2020 (UTC)
- Lo que hacen las wikipedias hindi y bengalí con las etiquetas de código auxiliar es asunto suyo. Tal vez tengan reglas que no solo se refieran a la longitud del artículo, como la cantidad de referencias o la calidad de la escritura. O tal vez la persona que crea estos artículos de menos de 100 palabras simplemente no conoce las etiquetas de código auxiliar. Cualquiera sea la razón, no tiene nada que ver con nosotros; no podemos decirles cómo manejar las etiquetas stub en sus Wikipedias. - Red rose64 🌹 ( charla ) 15:14, 18 de agosto de 2020 (UTC)
- Sí, no muchos editores saben cómo agregar o eliminar etiquetas Stub, qué criterios deben cumplirse para clasificar algún artículo como Stub o eliminar la etiqueta Stub, que es la razón por la que apoyo la eliminación de etiquetas Stub por completo. Después de todo, la etiqueta Stub en Wikipedia en inglés puede ser muy engañosa a veces (consulte este enlace web https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Long_stubs , que ya mencioné anteriormente, para ver el largo, artículos bien referenciados que todavía están etiquetados como Stubs, y la mayoría de las etiquetas Stub en la lengua vernácula india popular (como el hindi y el bengalí). Las wikipedias son inútiles y, en los artículos en los que se requiere, los editores no lo ponen allí. Un ejemplo de sub -El artículo Stub de 100 palabras en Wikipedia en hindi es este, https://hi.m.wikipedia.org/wiki/%E0%A4%A7%E0%A5%8D%E0%A4%B0%E0%A5%81 % E0% A4% B5_% E0% A4% B0% E0% A4% BE% E0% A4% A0% E0% A5% 80 que trata sobre un popular youtuber indio. Soukarya ( charla ) 15:34, 18 de agosto de 2020 ( UTC)
- Wikipedia en hindi no tiene nada que ver con nosotros . Si desea cambiar sus prácticas, hágalo en sus foros de discusión, no aquí. - Red rose64 🌹 ( charla ) 17:00, 18 de agosto de 2020 (UTC)
- Sí, no muchos editores saben cómo agregar o eliminar etiquetas Stub, qué criterios deben cumplirse para clasificar algún artículo como Stub o eliminar la etiqueta Stub, que es la razón por la que apoyo la eliminación de etiquetas Stub por completo. Después de todo, la etiqueta Stub en Wikipedia en inglés puede ser muy engañosa a veces (consulte este enlace web https://en.wikipedia.org/wiki/Wikipedia:Database_reports/Long_stubs , que ya mencioné anteriormente, para ver el largo, artículos bien referenciados que todavía están etiquetados como Stubs, y la mayoría de las etiquetas Stub en la lengua vernácula india popular (como el hindi y el bengalí). Las wikipedias son inútiles y, en los artículos en los que se requiere, los editores no lo ponen allí. Un ejemplo de sub -El artículo Stub de 100 palabras en Wikipedia en hindi es este, https://hi.m.wikipedia.org/wiki/%E0%A4%A7%E0%A5%8D%E0%A4%B0%E0%A5%81 % E0% A4% B5_% E0% A4% B0% E0% A4% BE% E0% A4% A0% E0% A5% 80 que trata sobre un popular youtuber indio. Soukarya ( charla ) 15:34, 18 de agosto de 2020 ( UTC)
- Lo que hacen las wikipedias hindi y bengalí con las etiquetas de código auxiliar es asunto suyo. Tal vez tengan reglas que no solo se refieran a la longitud del artículo, como la cantidad de referencias o la calidad de la escritura. O tal vez la persona que crea estos artículos de menos de 100 palabras simplemente no conoce las etiquetas de código auxiliar. Cualquiera sea la razón, no tiene nada que ver con nosotros; no podemos decirles cómo manejar las etiquetas stub en sus Wikipedias. - Red rose64 🌹 ( charla ) 15:14, 18 de agosto de 2020 (UTC)
- ¿No? Alguien puede corregirme si me equivoco, pero creo que más de la mitad de los artículos del proyecto son resguardos. Entonces ... Vamos a deshacernos de cientos de plantillas y editar millones de artículos porque? ... Hay un sentimiento generalizado de indiferencia por su utilidad? Lo siento. Ese no es un proyecto que emprendes cuando el argumento principal es "meh". Si no te gustan, no los uses. Nadie te va a arrastrar a ANI porque no estás particularmente interesado en la clasificación de códigos auxiliares. G M G talk 13:34, 18 de agosto de 2020 (UTC)
- Oponerse , solución buscando un problema. Sofocar ( charla ) 16:05, 21 de agosto de 2020 (UTC)
- Oponerse . No me convencen los argumentos a favor. Podría estar convencido de que la información del talón no debería estar visible en la página del artículo, ya que a los lectores no les va a importar, ya pueden decir que es un artículo corto, sin necesidad de que los ayudemos. También estaría de acuerdo con algunas de las otras sugerencias hechas, como hacer que la etiqueta de código auxiliar sea invisible si un WikiProject ha evaluado el artículo anterior en la página de discusión, u ocultar la etiqueta por encima de un determinado tamaño de artículo. Pero deshacerse de ellos es tirar al bebé con el agua del baño; Existen usos legítimos para los talones que superan los beneficios menores discutidos anteriormente. Mike Christie ( charla - contribuciones - biblioteca ) 16:20, 21 de agosto de 2020 (UTC)
- Oponerse Tener más de una forma de agrupar y acceder a los artículos de resguardo para trabajar es totalmente sensato, por lo que esta es una propuesta tonta. Eliminarlos solo debilitaría el Proyecto. Dicho esto, la categorización de 'stub' en la página de un artículo, aunque pasa desapercibida para la gran mayoría de los lectores, realmente debe coincidir con las evaluaciones de WikiProject de la página Talk. Confieso que a menudo modifico el último, pero me olvido de eliminar el primero. Si no existe un acuerdo para que un bot haga el trabajo de eliminar las etiquetas stub obsoletas, entonces al menos una herramienta para identificar la falta de coincidencia entre las páginas de discusión podría ser valiosa para algunos editores. Personalmente, lo que encuentro frustrante es tener que cambiar individualmente tres o cuatro evaluaciones 'stub' en las páginas de Discusión, una para cada WikiProject, cuando esa evaluación será la misma en todos ellos. Las evaluaciones de calidad realmente podrían ser integradas, de modo que solo sea necesario cambiar una, dejando que la evaluación de "importancia" sea específica para cada WikiProject individual. Solo pensé en tirar eso por ahí. Nick Moyes ( charla ) 19:18, 21 de agosto de 2020 (UTC)
- Aunque en la mayoría de los casos deberían ser iguales, y de hecho es una molestia tener que cambiar varios, hay muchos casos en los que es totalmente apropiado tener diferentes calificaciones para diferentes proyectos, especialmente cuando un proyecto solo se aplica a una parte del proyecto. sujeto. Obviamente, ese es el caso con mucha más frecuencia para las calificaciones de importancia, por lo que es posible que deba editar cada línea de todos modos. Johnbod ( charla ) 20:33, 21 de agosto de 2020 (UTC)
- Oponerse : los stubs todavía tienen sus usos y, como se señaló anteriormente, no interfieren con los lectores, ya que están directamente en la parte inferior de los artículos. Son inofensivos y, en mi humilde opinión, no veo ninguna razón válida para eliminarlos o desaprobarlos. - Comentario anterior sin firmar agregado por Davey2010 ( charla • contribuciones )
- Oponerse . Es una política de larga data que Wikipedia es un trabajo en progreso , y las etiquetas stub son uno de los reflejos más visibles de eso. Sin embargo, ha habido una tendencia hacia la intolerancia de los talones, y los talones que habrían sido perfectamente aceptables en 2006 ahora se redactan rutinariamente sin discusión. Las etiquetas de código auxiliar sirven como recordatorio de que los códigos auxiliares son una parte natural de Wikipedia, y me preocupa que eliminarlos impulse aún más esa intolerancia. - Paul_012 ( charla ) 09:57, 28 de agosto de 2020 (UTC)
- Oponerse : como usuario de User: Anomie / linkclassifier.js, las etiquetas stub y las categorías correspondientes son las que hacen que estos enlaces aparezcan con un color diferente mientras navego por Wikipedia, a su vez, utilizo esto para encontrar artículos que podría ser interesado en mejorar. Sin embargo, no me opondría a un rediseño. CSJJ104 ( charla ) 14:54, 30 de agosto de 2020 (UTC)
- Oponerse : es simplemente una invitación a expandir el artículo, que es lo que realmente necesita Wikipedia. Eliminar notas de resguardo oculta la vergüenza que tiene gran parte de wikipedia: investigación y cobertura de temas inadecuadas. - ishwar (hablar) 05:05, 31 de agosto de 2020 (UTC)
- Oponerse : estoy de acuerdo con los comentarios anteriores de que los talones son útiles y ayudan a animar a los lectores a considerar la posibilidad de ampliar el artículo. También he visto demasiados stubs perfectamente aceptables obtener AFD en lugar de que alguien tome la iniciativa de expandirlos. Me gusta mucho la sugerencia anterior de Awesome Aasim y Ed6767 de una etiqueta de mantenimiento "amigable" que anime a los lectores a expandir el artículo. Carter ( charla ) 00:29, 1 de septiembre de 2020 (UTC)
- Oponerse - por cinco razones: (1) Creo que son útiles para los nuevos editores. ¿Todas esas cosas de "Be Bold"? Estaba aterrorizado de hacer ediciones cuando me inscribí por primera vez. Pensé que cualquier cosa que hiciera me llamaría frente a la Cámara Estelar de Wikipedia. Pero luego comencé a ver avisos en los artículos que estaba leyendo, invitándome a intentar mejorarlos. Eso es lo que me hizo empezar a hacer ediciones (cautelosas), a páginas de código auxiliar que conocía un poco. Las notas auxiliares son invitaciones a los nuevos editores: "Lo decimos en serio, trata de mejorar este artículo, ¡pruébalo!" (2) Son discretos. Justo en la parte inferior de la página, no interfieren en la lectura del artículo en absoluto. Si lee hasta aquí, obtiene el reconocimiento de que este artículo podría ser mejor y la invitación a intentar solucionarlo. (3) Por el contrario, agregar grandes notas de sombrero en la parte superior de una página, como se sugiere en el subproceso, es decir "Este artículo es una mierda, no debes confiar en él, pero si puedes, puedes intentar mejorarlo. " En realidad, no es un gran aliciente leer el artículo. (4) ¿Hay páginas de Discusión? ¿Quien sabe? ¿Por qué no me dijeron? (5) A medida que he aprendido más sobre los stubs y la intrincada conexión con las categorías, los encuentro muy útiles para ver las interconexiones entre diferentes artículos dentro del mismo tema, y particularmente aquellos que necesitan ser mejorados. - Sr. Serjeant Buzfuz ( charla ) 03:36, 1 de septiembre de 2020 (UTC)
- Oponerse : este es un gran problema y debe revisarse teniendo en cuenta sus efectos a largo plazo. Si bien las etiquetas de código auxiliar pueden no ser directamente eficaces para expandir los artículos de código auxiliar, creo que las etiquetas de código auxiliar son muy útiles para Wikipedia, porque le dan a todos los lectores la sensación de que "personas como usted pueden unirse a Wikipedia". Esta es una parte vital de cómo algunos lectores se convierten en editores, y yo diría que un buen porcentaje de editores no se habría unido si no fuera por las etiquetas stub u otras etiquetas similares que indiquen cómo podrían ayudar; no habrían sabido que puedes editar Wikipedia. Si no fuera por las etiquetas stub, Wikipedia se sentiría más como un libro que como una comunidad abierta, y si no tuviera esta sensación acogedora, si el número de editores en Wikipedia se redujera, la calidad de los artículos en general disminuiría. Decidí oponerme en lugar de esperar a la encuesta porque creo que una encuesta no podría mostrar los efectos que tengo en mente, ya que solo se sentirían si se usara un gran porcentaje de artículos. Si bien es cierto que los stubs pueden permanecer en los artículos después de que su clase haya aumentado, esto generalmente no es un problema para el lector, especialmente porque en los artículos más grandes, las etiquetas stub son difíciles de realizar. Solo captan su atención si en realidad está mirando un fragmento, cuando son algunas de las pocas grietas del texto en ese artículo. Si bien la destubificación puede ser un apuro para los editores, es una necesidad que surge de una parte necesaria de la estructura de Wikipedia.
KnolGua ( charla ) 09:53, 2 de septiembre de 2020 (UTC)
- Siempre pensé que eran inútiles. Soporte . Foxnpichu ( charla ) 14:43, 3 de septiembre de 2020 (UTC)
Dejar de lado las citas entre paréntesis
- La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.
Propongo que desaprovechemos formalmente el estilo de cita entre paréntesis en línea .
Wikipedia ha valorado durante mucho tiempo los diferentes estilos de citas , y protegemos formalmente una amplia gama de estilos de citas. Incluso hubo un caso de ArbCom en 2006 que falló sobre el tema. Sin embargo, eso fue hace 14 años y muchas cosas han cambiado desde entonces. A medida que Wikipedia avanza y nuestro estilo se vuelve más estandarizado y formal, cuestiono la utilidad del estilo de citas entre paréntesis que rara vez se usa . Este estilo existe porque se usa en artículos científicos y ensayos universitarios. Sin embargo, los trabajos y ensayos no tienen la ventaja de estar en línea; por lo tanto, no pueden tener notas a pie de página expandibles con codificación elegante. Las citas entre paréntesis también abarrotan el texto y dificultan la lectura. Véase, por ejemplo , Actuario , que es uno de los pocos FA con estilo de cita entre paréntesis. Incluye oraciones como En varios estudios, ser actuario ocupó el puesto número uno o dos varias veces desde 2010 (Thomas 2012, Weber 2013, CareerCast 2015) y entre los 20 primeros durante la mayor parte de la última década (CareerCast 2014, CareerCast 2016, CNN Money 2017, CareerCast 2019).
que está abarrotado e innecesariamente largo debido a las citas. Al final del día, nuestro objetivo es servir al WP: READER . La mejor manera de hacerlo es proporcionar artículos fáciles de leer, libres de desorden en línea. CaptainEek edita Ho Cap'n! ⚓ 20:38, 5 de agosto de 2020 (UTC)
- La ruptura arbitraria más reciente es la siguiente: # ruptura arbitraria 4 (citas) . Steel1943 ( charla ) 16:14, 4 de septiembre de 2020 (UTC)
- Nota Ha habido cierta confusión sobre la redacción, así que permítanme aclararlo. No propongo que prohibamos TODAS las referencias entre paréntesis. Simplemente propongo que no usemos paréntesis de texto en línea, no basados en software. Esta NO es una propuesta para prohibir Template: sfn o Template: Harv (siempre que esté anidada correctamente en una etiqueta de referencia). El único objetivo es lograr que en lugar de ver
Ipsum lorem facto (Eek, 2020)
, terminamos conIpsum lorem facto
con un pequeño número de referencia azul al final, lo que lleva a una nota al pie que todavía puede decir "(Eek, 2020)". Como mencioné a continuación, creo que la mejor solución para las referencias existentes es simplemente convertirlas a sfn. CaptainEek edita Ho Cap'n! ⚓ 19:44, 6 de agosto de 2020 (UTC)- Nota tras nota En cuanto a la otra arruga principal: el uso de
El artículo de Eek (2020) mostró
yEek (pág. 35)
. También sugiero que esto se elimine gradualmente, en aras de la coherencia. CaptainEek edita Ho Cap'n! ⚓ 20:09, 6 de agosto de 2020 (UTC)- CaptainEek , creo que sería una aclaración útil aquí si, además de indicar su intención para el RfC, da un ejemplo del cambio de redacción a CITEVAR (o en cualquier otro lugar) que cumpla con esas intenciones. Mike Christie ( charla - contribuciones - biblioteca ) 16:23, 31 de agosto de 2020 (UTC)
- Nota tras nota En cuanto a la otra arruga principal: el uso de
Agregue una viñeta a WP: CITEVAR # Generalmente se considera útil :
- Conversión de referencias entre paréntesis en notas al pie numeradas, a menos que se apliquen 1 o 2 a continuación, o ambos:
- El artículo trata sobre un tema para el cual, en fuentes confiables, se usan comúnmente referencias entre paréntesis, y existe un consenso establecido en la página de discusión del artículo de que el artículo solo usará referencias entre paréntesis.
- La conversión crea un lío.
Esta propuesta de implementación busca un camino intermedio entre ideas de implementación muy duras (p. Ej., Desaprobar por completo y / o hacer cumplir por bot) e ideas de implementación más suaves (p. Ej., Desaprobar solo para páginas nuevas), ambas direcciones ya se han elaborado en el área de la encuesta a continuación. - Francis Schonken ( charla ) 09:13, 2 de septiembre de 2020 (UTC)
Inicio de la encuesta (citas)
- Soporte como nom. Entiendo que habrá algunos desafíos tácticos para la desaprobación, pero no creo que sean insuperables y que puedan resolverse aquí mediante la discusión. CaptainEek edita Ho Cap'n! ⚓ 19:37, 4 de agosto de 2020 (UTC)
- Pregunta Las bajas pueden ser de varias formas. Hay desaprobación cuando simplemente decimos "esto ya no es una buena idea, los artículos nuevos no deberían hacer esto", hay desaprobación cuando decimos "los editores pueden reemplazar esto a menos que haya un consenso específico en contra de hacerlo" y "los editores deberían eliminar esto cuando se encuentra ". ¿A qué forma de desaprobación apunta esta propuesta? - AntiCompositeNumber ( conversación ) 19:43, 4 de agosto de 2020 (UTC)
- AntiCompositeNumber , una de las dos primeras opciones: "los artículos nuevos no deberían hacer esto", o "reemplazar a menos que haya consenso en contra". No creo que debamos eliminarlo en todos los lugares a cualquier costo. Sin embargo, lo dejé un poco abierto porque creo que depende de la comunidad decidir qué versión piensan mejor. CaptainEek edita Ho Cap'n! ⚓ 19:46, 4 de agosto de 2020 (UTC)
- Diecinueve años y 6 millones de artículos, yo diría que la opción 1 tendría tan poco efecto general que sería bastante inútil. - Mandruss ☎ 08:28, 5 de agosto de 2020 (UTC)
- AntiCompositeNumber , una de las dos primeras opciones: "los artículos nuevos no deberían hacer esto", o "reemplazar a menos que haya consenso en contra". No creo que debamos eliminarlo en todos los lugares a cualquier costo. Sin embargo, lo dejé un poco abierto porque creo que depende de la comunidad decidir qué versión piensan mejor. CaptainEek edita Ho Cap'n! ⚓ 19:46, 4 de agosto de 2020 (UTC)
- Soporta no aceptarlo en nuevos artículos. Como lector, lo encuentro la forma más hostil de estilo de cita en los artículos. editar para agregar una aclaración basada en una extensa discusión siguiente : Para artículos nuevos, apoyo no aceptar el uso de citas de solo texto entre paréntesis que no creen notas al pie de página con hipervínculos, como (Smith, 2012) . Tengo entendido que este RfC no se trata de ningún otro tipo de cita entre paréntesis. fin de texto añadido Schazjmd (charla) 19:51, 4 de agosto de 2020 (UTC)
- Soporte Hace que los artículos sean más difíciles de leer. - Charla Susmuffin 19:55, 4 de agosto de 2020 (UTC)
- Soporte hasta el punto de no permitir ningún artículo nuevo usando el estilo y permitir la actualización de ejemplos existentes a plantillas a menos que haya consenso en contra. La curva de aprendizaje aquí es mínima, especialmente con las herramientas de citas tanto en la fuente como en el editor visual, y la ganancia en legibilidad es muy sustancial. - Elmidae ( charla · contribuciones ) 22:28, 4 de agosto de 2020 (UTC)
- Me débilmente apoyo la desaprobación citas entre paréntesis se mueve hacia adelante , y prefiriendo formalmente nuestro software soportado por el sistema, que nota al pie en mi opinión es claramente superior, pero estoy tibia sobre la conversión de los artículos existentes, especialmente cuando eso sería frustrante para algunos editores. Lo último que quiero ver es algún colaborador productivo perseguido por su preferencia de estilo de cita, especialmente los usuarios "menos técnicos" que se sienten incómodos con nuestra sintaxis de notas al pie similar a XML. Una preferencia formal es una cosa, pero una regla estricta para no usar un estilo en particular es otra. VisualEditor mejora este problema pero no lo elimina. {{ Nihiltres | hablar | ediciones }} 22:39, 4 de agosto de 2020 (UTC)
- CaptainEek y Nihiltres , hace "nuestro software soportado por el sistema nota al pie" medias
etiquetas, o incluye plantillas como Plantilla: SFN y Plantilla: Harv ? No estoy seguro de si el objetivo es producir los pequeños números de clic azules, o hacer posible que un bot determine de manera confiable si hay referencias en una página, o producir una cierta cantidad de estandarización para los editores (es decir, tan las habilidades de citación que aprenda en un solo lugar se transferirán a todos los artículos). WhatamIdoing ( charla ) 15:18, 5 de agosto de 2020 (UTC)
- WhatamIdoing , incluyo sfn como software compatible, solo soy compatible con Harvard siempre que estén en etiquetas de referencia. El objetivo es hacer esos pequeños números azules, lograr una mayor estandarización y facilitar las cosas a nuestros lectores. CaptainEek edita Ho Cap'n! ⚓ 19:34, 6 de agosto de 2020 (UTC)
- WhatamIdoing incluyo {{ sfn }} y similar en "compatible con software"; dan salida a
etiquetas o equivalentes (
{{#tag:ref}}
), por lo que son parte del sistema soportado por software. De hecho, me gusta el patrón de usar referencias al estilo de Harvard para referencias citadas repetidamente en la lista de referencias, por lo que vale. {{ Nihiltres | hablar | ediciones }} 20:38, 10 de agosto de 2020 (UTC)- Nihiltres , Template: Harv produce esto: ( Smith 2005 , p. 25)
{{harv|Smith|2005|p=25}}
). WhatamIdoing ( charla ) 01:57, 11 de agosto de 2020 (UTC) y solo obtendrás etiquetas de referencia si envuelves la plantilla en ellas (es decir,
- Nihiltres , Template: Harv produce esto: ( Smith 2005 , p. 25)
- CaptainEek y Nihiltres , hace "nuestro software soportado por el sistema nota al pie" medias
- Apoyo a convertirlo en el status quo para los artículos nuevos y para los artículos más antiguos, permitiendo que otros cambien el estilo de las citas a no entre paréntesis (pero sin degradar automáticamente los FA y GA solo porque todavía están usando el estilo entre paréntesis). Sam-2727 ( conversación ) 23:12, 4 de agosto de 2020 (UTC)
- Me opongo , creo que, a fin de cuentas, esto es un neto negativo. Definitivamente estoy de acuerdo en que las citas entre paréntesis en línea no están ni cerca de nuestro estilo preferido o del estilo que los lectores necesariamente esperan de nosotros, pero creo que los daños son exagerados. Es un formato raro en Wikipedia, pero no es un formato raro; Me sorprendería que la mayoría de nuestros lectores no estén familiarizados con los estilos de citas entre paréntesis. ¿Interrumpe el flujo de la prosa? Probablemente, pero al igual que los pequeños números azules y las etiquetas {{ cn }} que tenemos en línea, los lectores aprenden rápidamente a ignorarlos y pasarlos por alto. Definitivamente no son ideales, pero dudo que los estilos de citas entre paréntesis nos estén haciendo perder un número significativo de lectores. Lo que me hace oponerme es que, en discusiones como estas, la gente tiende a pasar por alto los beneficios de permitir variantes de citas impopulares. La mayoría de las personas se han encontrado con estilos de citas entre paréntesis en algún momento de sus vidas. Imagínese si le dijera que para participar de manera efectiva en Wikipedia no solo necesita aprender un nuevo estilo de cita, sino también las trampas tecnológicas que conlleva su uso. La mayoría de la gente odia los estilos de citas de todos modos, por lo que al lanzar un maratón de edición o reclutar editores, es mucho más fácil entusiasmar a la gente con la contribución cuando puedo decir "cítelo como lo haría en uno de sus artículos". Esa línea funciona tanto para estudiantes como para profesores; ya saben cómo hacer citas entre paréntesis, y permitir citas entre paréntesis reduce la curva de aprendizaje para muchas personas. VisualEditor ha ayudado, pero no es perfecto y no a todo el mundo le gusta usarlo (entre los programadores informáticos con los que trabajo, en realidad les gusta el texto fuente en lugar del editor WYSIWYG). Entre los expertos en la materia, la cita entre paréntesis es el estilo dominante. Muchos académicos y revistas publican artículos de acceso abierto bajo términos compatibles con nuestra licencia. Permitir citas entre paréntesis significa que si un académico publica un artículo de acceso abierto en una revista que lo licencia bajo CC-BY-SA, podemos simplemente copiar la sección de revisión iluminada y tenemos un nuevo artículo revisado por pares y escrito por un experto en la materia. Al desaprobar este formulario de cita, también aumenta las oportunidades para que los novatos muerdan. Si alguien escribe un artículo agradable que usa citas entre paréntesis (o copia un artículo de revista con la licencia correspondiente), y el patrullero de NP llega y de repente cambia todo, eso será desalentador en el mejor de los casos.
Esto no es ni siquiera descabellado, cambios de estilo de citas al por mayor y las disputas interpersonales que surgieron de ellos son lo que condujo al caso citevar ArbCom, por lo que no estoy dispuesto a abrir las puertas a eso nuevamente.(Vea la discusión a continuación) De manera similar, es desalentador escribir un artículo e inmediatamente que le digan que hay reglas de citas no escritas que debe aprender antes de participar. Tener una política laxa sobre los estilos de citas es un beneficio para el proyecto. Ninguno de estos son motivos para fomentar el uso de citas entre paréntesis, pero son motivos por los que no deberíamos prohibirlo. Según WP: CITEVAR , ya podemos cambiar los estilos de citas por consenso, por lo que esta propuesta solo cerraría la puerta a muchos beneficios posibles. Decir "usa cualquier estilo de cita que te guste" es un beneficio, y no debemos cambiar ese principio general. Si alguna página puede mejorarse cambiando el estilo de la cita, sea atrevido (pero no imprudente) o inicie una discusión para cambiarlo. Pero la enciclopedia no es mejorada por una manta de desaprobación o prohibición de un estilo de citación de otro modo válido y bien usado. En mi opinión, los daños superan con creces los beneficios de una prosa ligeramente mejorada. - Wug · a · po · des 23:16, 4 de agosto de 2020 (UTC)- Wugapodes , ¿qué caso ArbCom es "el caso citevar ArbCom"? WhatamIdoing ( charla ) 01:30, 7 de agosto de 2020 (UTC)
- @ WhatamIdoing : Wikipedia: Requests_for_arbitration / Sortan # Preferred_styles . Lo llamé así porque está citado en WP: CITEVAR , pero al leerlo nuevamente, creo que describí mal la disputa. Vahurzpu lo caracteriza mejor a continuación, y he golpeado esa frase de arriba. El punto general que estaba tratando de hacer es que tenemos casos de personas que cambian artículos a su estilo preferido y, a menudo, esto conduce a un conflicto poco saludable. El caso de Sortan es un ejemplo, otro es un caso de ArbCom de 2005 sobre guerras de edición de infobox, y WP: Don't edit war sobre el color de las plantillas llega al anti-patrón general. - Wug · a · po · des 01:58, 7 de agosto de 2020 (UTC)
- Gracias, agradezco los enlaces. WhatamIdoing ( charla ) 03:10, 7 de agosto de 2020 (UTC)
- @ WhatamIdoing : Wikipedia: Requests_for_arbitration / Sortan # Preferred_styles . Lo llamé así porque está citado en WP: CITEVAR , pero al leerlo nuevamente, creo que describí mal la disputa. Vahurzpu lo caracteriza mejor a continuación, y he golpeado esa frase de arriba. El punto general que estaba tratando de hacer es que tenemos casos de personas que cambian artículos a su estilo preferido y, a menudo, esto conduce a un conflicto poco saludable. El caso de Sortan es un ejemplo, otro es un caso de ArbCom de 2005 sobre guerras de edición de infobox, y WP: Don't edit war sobre el color de las plantillas llega al anti-patrón general. - Wug · a · po · des 01:58, 7 de agosto de 2020 (UTC)
- Wugapodes , ¿qué caso ArbCom es "el caso citevar ArbCom"? WhatamIdoing ( charla ) 01:30, 7 de agosto de 2020 (UTC)
- Fuerte oposición Lo importante es que los artículos sean citados. La forma en que se citan es mucho menos importante. Una vez que tenemos una cita, se puede mejorar. Muchos usuarios poco sofisticados no saben cómo formatear una cita en ninguno de nuestros métodos preferidos, y deberíamos hacer todo lo posible para alentarlos a agregar la referencia de todos modos, en el método que elijan, por informal que sea. Los métodos oficiales de citas en Wikipedia se encuentran entre las partes más complicadas del proyecto que verá el escritor de artículos ordinario. En nuestros esfuerzos por estandarizarlos, también los hemos hecho más intimidantes. Sería muy contraproducente para un escritor principiante intentar agregar un artículo y no lograr que lo aceptaran porque no saben cómo citarlo. Después de muchos años aquí, y décadas trabajando con citas en general en el mundo académico y bibliotecario, nunca había visto un sistema tan complicado y pobremente documentado como el nuestro (Tenemos documentación igualmente pobre en otros lugares, pero no para una función tan importante y tan frecuente ), Conozco todos los diversos dispositivos para ayudar a las personas a obtener una cita en uno de los formatos correctos actualmente; A veces los uso, aunque todavía no he conseguido siempre conseguir lo que me propongo. Pero también conozco (o al menos conozco) los diversos dispositivos y bots que tenemos para mejorar las citas; o, más exactamente, forzándolos en nuestros formatos preferidos. Lo que estoy diciendo aquí ha sido dicho con más detalle justo arriba por Wugapodes . DGG ( charla ) 00:48, 5 de agosto de 2020 (UTC)
- Apoyo : señalando que esta propuesta no es para "bombardear
citarvista ", sino" alejarse de ", y apoyo alejarse de las citas entre paréntesis. Eso podría significar desalentarlos en los documentos de políticas, no aceptarlos en artículos nuevos o cambiar los artículos que los usan a un estilo diferente (pero Wikipedia es para una audiencia general; no es como una revista revisada por pares; y nuestra audiencia global, que se inclina desde muy jóvenes (estamos escribiendo para qué nivel de comprensión del lector ?) no estará familiarizado con las citas entre paréntesis. Las notas a pie de página son mucho más comunes fuera de la academia; de hecho, las citas entre paréntesis no se usan realmente fuera de la redacción académica formal, del tipo regido por, por ejemplo, las guías de estilo MLA o APA. la prosa: en mi opinión, no es una mejora "menor" de la prosa, sino una importante, para deshacerse de los paréntesis. Y distraen mucho más que las notas al pie de página. Quiero decir, solo mire: aquí hay una oración con un paréntesis citación. (Levivich 2014). Aquí hay una oración con una nota al pie de página. [1] I t Piense que el escaneo de la nota al pie es mucho más fácil. En cuanto a la creación de citas, la cita más fácil de crear es bare url . La segunda forma más fácil de agregar una referencia es hacer clic en el botón "citar" (ya sea que uno esté usando un editor visual o no). Mientras que en realidad se crean citas entre paréntesis en un artículo wiki (que enlaza con el elemento de bibliografía real), uno debe dominar las plantillas de citas que son más oscuras que {{ cite }}, como {{ harv }}. Quiero decir, solo lee WP: PAREN , no es fácil. Por lo tanto, los nuevos usuarios no buscarán citas entre paréntesis. Y, de hecho, es por eso que las citas entre paréntesis son raras, mientras que las etiquetas ref en URL desnudas y las citas del editor visual (ya sabes, las encantadoras ) son mucho más comunes. TLDR : las citas entre paréntesis son más difíciles para los lectores y más difíciles para los nuevos editores; es hora de deshacerse de él. Le v ! v ich 01:03, 5 de agosto de 2020 (UTC) - Soporte . No hay nada de malo en las citas entre paréntesis, pero debemos apuntar a un formato consistente siempre que sea posible y las citas de notas al pie son el estándar abrumador de facto . Re. Se oponen Wugapodes y DGG: esto no impedirá que los nuevos editores usen citas entre paréntesis. Simplemente significa que alguien vendrá más tarde y los estandarizará, como sucede cuando los novatos usan citas sin formato, o mayúsculas y minúsculas en los encabezados, o cualquier otro número de detalles de WP: MOS , sin gran alboroto. Creo que la idea de que disuadirá a académicos y estudiantes también es una pista falsa. Incluso dentro de un campo, las diferentes publicaciones insisten en diferentes estilos de citas. No creo que a la gente le resulte sorprendente o desagradable saber que Wikipedia también tiene un estilo propio. - Joe ( charla ) 07:35, 5 de agosto de 2020 (UTC)
- Oponerse por Wugapodes . En resumen, desaprobar las citas entre paréntesis (incluso solo para artículos nuevos y, de hecho, especialmente para artículos nuevos) perjudicará a los siguientes grupos de editores: 1) Nuevos editores . Los nuevos editores deben poder contribuir con contenido de calidad con la menor cantidad de problemas relacionados con cosas que no están relacionadas con nuestros principios básicos, como la verificabilidad. De todos los estilos de citas, algunos novatos pueden estar más familiarizados con las citas entre paréntesis (por ejemplo, debido a su experiencia académica). De hecho (contra Levivich arriba), las citas entre paréntesis son el único tipo de estilo de cita que uno puede producir sin ningún conocimiento sobre wikitexto (como etiquetas de referencia) o plantillas. 2) Editores que importen material de dominio público o de licencia libre . Para que esto sea conveniente, la prioridad número uno debe ser importar fácilmente el material en primer lugar. Cualquier "wikificar" es secundario. Convertir el estilo de cita del material fuente puede ser una tarea ardua, y puede haber casos en los que haya situaciones excepcionalmente complicadas, como una fuente que usa repetidamente "In Smith (2008), se argumenta ..." y otras abreviaturas que fundamentalmente altera la organización de la prosa. Personalmente he experimentado esto al armonizar artículos que mezclan de manera inconsistente los dos estilos de citas. 3) Editores establecidos que prefieren las citas entre paréntesis . Si para algunos la elección es entre contribuir usando ese estilo o dejar de contribuir, todos perdemos. 4) Al final, todos los editores (y lectores) se ven beneficiados . Nunca utilizo citas entre paréntesis; No es mi estilo preferido. Pero a los que sí lo hacen, les ayuda a contribuir y eso es lo que queremos animar, no desanimar. Las citas están ahí para garantizar que WP: V y las citas entre paréntesis lo hagan tan bien como cualquier otro estilo. Se requiere un estilo de cita coherente dentro de un artículo, pero hemos acordado no exigir coherencia entre todos los artículos en lo que respecta a la variedad de citas (y fechas e inglés). La política actual ya permite cambiar el estilo de las citas de un artículo caso por caso. Por lo tanto, si CaptainEek de buena fe encuentra que las citas entre paréntesis no son adecuadas para Actuario , puede solicitar que se modifiquen. - Finnusertop ( charla ⋅ contribuciones ) 08:25, 5 de agosto de 2020 (UTC)
- Dada la poca frecuencia con que se utilizan, me parece dudoso que el grupo demográfico de los nuevos editores que mencionas pueda averiguar sobre las citas entre paréntesis en primer lugar. Para hacerlo, uno tiene que navegar por la red bizantina (para un recién llegado, al menos) de páginas metainformativas y encontrar la guía apropiada de MoS, en lugar de encontrar un formato que tenga un ejemplo en casi todos los artículos. En cuanto a los editores que importan material externo, creo que si no tienen tiempo para cambiar el estilo de las citas (algo que se puede hacer fácilmente con un guión), probablemente no tengan tiempo para examinar adecuadamente el material. y determinar si es adecuado para Wikipedia. - Axisixa T C 01:11, 30 de agosto de 2020 (UTC)
- Apoye formalmente la preferencia por nuestro sistema de notas al pie con soporte de software y permita que otros cambien el estilo de las citas a no entre paréntesis para los artículos más antiguos. No deberíamos rechazar un artículo en la AFC debido a citas entre paréntesis, pero no debería haber ningún sesgo hacia cualquiera que se encargue de actualizar retrospectivamente los artículos existentes a sistemas de notas al pie con soporte de software. Cavalryman ( hablar ) 11:04, 5 de agosto de 2020 (UTC).
- Apoyo a la coherencia. El manual de estilo adopta todo tipo de posiciones arbitrarias, y esto es mucho más notorio que la mayoría. Debo señalar que, si la referencia de categoría: uso de Harvard es precisa, hay menos de mil de nuestros más de seis millones de artículos que usan este estilo. Apoyaría la desaprobación formal y permitir a los usuarios migrar el estilo de los artículos existentes, pero me detendría antes de rechazar nuevos artículos con el estilo. Simplemente comience a considerar {{ Use Harvard referencing }} una etiqueta de mantenimiento, y las personas que se preocupan por este tipo de cosas (posiblemente incluyéndome a mí) podrán migrar la sintaxis, al igual que la gente copia y edita artículos para que cumplan con WP: MOS . También debo señalar que el caso de ArbCom fue principalmente en el contexto de una única edición perturbadora de un usuario que se enfrentó a problemas de estilo, y la preservación de los estilos de citas, en particular, me parece (a mí) casi incidental al caso. Vahurzpu ( charla ) 15:56, 5 de agosto de 2020 (UTC)
- Advertencia: Usuario: Finnusertop afirma que Categoría: Usar referencias de Harvard no es de hecho muy precisa, por lo que "menos de mil" no debe tomarse como exacto. Sin embargo, diré que casi nunca encuentro artículos con referencias entre paréntesis, por lo que el punto general de "son muy raros" sigue en pie, al igual que el resto de mi comentario. Vahurzpu ( charla ) 01:51, 7 de agosto de 2020 (UTC)
- ¡Opónganse por los votos anteriores! La afirmación de que las citas entre paréntesis "abarrotan el texto y dificultan la lectura" parece más una cuestión de gusto que algo respaldado empíricamente; si el estilo fuera tan fundamentalmente malo, seguramente las guías de estilo de todas partes advertirían contra él, las publicaciones serias no lo usarían y las escuelas no lo enseñarían. XOR'easter ( charla ) 06:30, 6 de agosto de 2020 (UTC)
- Oponerse firmemente . Hay múltiples usos válidos de las citas entre paréntesis, incluso en los artículos que utilizan las referencias más comunes de Wikipedia en notas al pie: hacer referencia a una publicación en el texto por Autor (Año) en contextos en los que se trata de información enciclopédica en lugar de un mero desorden de referencias; hacer referencia a una página diferente en una nota al pie anterior colocando una cita entre paréntesis en otra nota al pie; dar una nota a pie de página abreviada a una referencia en un artículo que (debido a que hay muchas referencias o muchas referencias reutilizadas) mantiene las notas a pie de página breves y tiene una bibliografía más larga de referencias completas separadas de las notas a pie de página. Esta propuesta no hace distinción entre estos usos, ni entre el otro uso ahora menos común de tener citas entre paréntesis en línea en lugar de notas a pie de página, sino que simplemente los declara inválidos. Es una solución demasiado amplia para un no problema. Es la insensata consistencia de la que se nos ha advertido a todos. Es WP: CREEPy . Es una pendiente resbaladiza que va en contra de WP: CITEVAR y sienta un mal precedente que probablemente empeore con futuras eliminaciones de variaciones permitidas en las citas. Y hará demasiado trabajo para los gnomos en lugar de alentar a los editores a hacer el trabajo real de creación y limpieza de contenido. - David Eppstein ( charla ) 06:32, 6 de agosto de 2020 (UTC)
- @ CaptainEek : sin referencias entre paréntesis, ¿cómo propone exactamente dar formato a los artículos en los que muchas notas al pie se refieren a diferentes páginas dentro del mismo libro, como (para elegir un ejemplo de buen artículo) Hypatia ? (En realidad, Hypatia usa el estilo del año del autor sin paréntesis en sus notas al pie, pero es más o menos el mismo concepto que el que esta propuesta prohibiría). ¿Crees que la cita completa del libro debería repetirse una y otra vez en cada nota al pie por separado? ? ¿Cree que las referencias mágicamente entre paréntesis dentro de las notas a pie de página quedarían excluidas de su desaprobación a pesar de que su propuesta no dice nada sobre tales exclusiones? - David Eppstein ( charla ) 19:09, 6 de agosto de 2020 (UTC)
- David Eppstein , ¿Hypatia no parece usar un estilo entre paréntesis? Utiliza nuestro sistema sfn compatible, que creo que está muy bien. ¿Quizás haya un malentendido en cuanto a lo que quiero decir con el estilo entre paréntesis? Solo me refiero a la práctica de referencias entre paréntesis en línea que no crean referencias que puedan compilarse automáticamente en una lista de referencias. CaptainEek edita Ho Cap'n! ⚓ 19:21, 6 de agosto de 2020 (UTC)
- Si cree que no es un estilo entre paréntesis, entonces necesita hacer su propuesta mucho más específica para hacer coincidir lo que piensa más de cerca con lo que la propuesta realmente dice. El sistema sfn es un ejemplo de estilo entre paréntesis (dentro de notas al pie). Es irrelevante que el artículo utilice harvnb en lugar de harv o harvtxt dentro del formato (de modo que las notas al pie de página tengan el formato Año del autor en lugar de (Año del autor) o Autor (Año)); ese no es el nivel de detalle de la referencia estilo que deberíamos estar legislando. Su propuesta desaprueba el estilo entre paréntesis en todas partes, no simplemente el estilo entre paréntesis que se usa en línea únicamente para hacer referencia. Para otro ejemplo, mire el texto del artículo de Dehn invariante - en un punto el artículo dice "Dehn, en su tesis de habilitación de 1900 ..." mientras que más adelante tiene el texto "Como Dehn (1901) observó ...". El segundo ejemplo es una referencia entre paréntesis. Su propuesta la desaprobaría. Por lo tanto, es posible que haya pensado que estaba proponiendo solo un cambio en el estilo de referencia, pero en realidad está proponiendo imponer restricciones al contenido de nuestros artículos. Si no tenía la intención de realizar cambios tan radicales, le sugiero que retire su propuesta y piense más sobre qué es lo que realmente pretende lograr antes de proponer cambios de apariencia inofensiva que tienen efectos mucho más significativos de los previstos. - David Eppstein ( charla ) 19:30, 6 de agosto de 2020 (UTC)
- David Eppstein , ¿Hypatia no parece usar un estilo entre paréntesis? Utiliza nuestro sistema sfn compatible, que creo que está muy bien. ¿Quizás haya un malentendido en cuanto a lo que quiero decir con el estilo entre paréntesis? Solo me refiero a la práctica de referencias entre paréntesis en línea que no crean referencias que puedan compilarse automáticamente en una lista de referencias. CaptainEek edita Ho Cap'n! ⚓ 19:21, 6 de agosto de 2020 (UTC)
- @ CaptainEek : sin referencias entre paréntesis, ¿cómo propone exactamente dar formato a los artículos en los que muchas notas al pie se refieren a diferentes páginas dentro del mismo libro, como (para elegir un ejemplo de buen artículo) Hypatia ? (En realidad, Hypatia usa el estilo del año del autor sin paréntesis en sus notas al pie, pero es más o menos el mismo concepto que el que esta propuesta prohibiría). ¿Crees que la cita completa del libro debería repetirse una y otra vez en cada nota al pie por separado? ? ¿Cree que las referencias mágicamente entre paréntesis dentro de las notas a pie de página quedarían excluidas de su desaprobación a pesar de que su propuesta no dice nada sobre tales exclusiones? - David Eppstein ( charla ) 19:09, 6 de agosto de 2020 (UTC)
- Oponerse : no puedo agregar nada a esos puntos opuestos bien argumentados anteriores. - Michael Bednarek ( charla ) 07:48, 6 de agosto de 2020 (UTC)
- Soporte Este es difícil ya que odio las citas entre paréntesis, pero esto parece CREEP y, por lo tanto, me sorprende que haya recibido la cantidad de soporte que tiene (y todavía no estoy seguro de que pase). Lo que me lleva a esta posición de todos modos es que a) nadie lee el MoS antes de unirse, por lo que no van a decir "¡Oh, no puedo esperar para agregar un artículo de Wikipedia!" y luego quedarnos escandalizados y descorazonados por nuestro conjunto bastante grande de minucias de estilo, b) los lectores siempre serán órdenes de magnitud más numerosos que los editores, y las notas al pie de página son, en última instancia, más fáciles de leer que las citas entre paréntesis (aunque solo sea levemente), yc) Levivich et al. me han convencido de que esta es una solución más suave de lo que podría parecer. Esto podría (el énfasis podría ) también mejorar la accesibilidad al hacer que las citas sean notas especiales a pie de página para el uso de software de lectura de pantalla (sin mencionar que se puede enfocar) en lugar de texto sin formato. - John M Wolfson ( charla • contribuciones ) 11:07, 6 de agosto de 2020 (UTC)
- Enérgicamente en contra : La propuesta asume erróneamente que solo hay dos estilos de citas: autor-fecha y nota al pie . Pero también hay un estilo híbrido (llamarlo corto cita ), donde se utilizan las citas cortas (autor-fecha) dentro de las notas al pie usando {{ harvtxt }} y {{ harvnb }} y {{ SFN }} plantillas. Al usar este estilo híbrido, ocasionalmente es útil usar una plantilla {{ harvtxt }} dentro del cuerpo del artículo, aunque el estilo general es de citas breves , evitando así los problemas de legibilidad del estilo de fecha de autor mencionados en la propuesta. Una ventaja importante de autor-fecha y corto citar estilos es que la lista de referencia es (normalmente) ordenados según nombre del autor, que es extremadamente útil en campos como las ciencias humanas y sociales, donde algunos estudios nombres de los autores son especialmente importantes. He discutido por qué esto es así en Talk: Psychotherapy § Estilo de cita , donde escribí:
En segundo lugar, su afirmación de que a los usuarios de Wikipedia no les importan los nombres de los autores ignora la variabilidad en el tema de los artículos de Wikipedia y en los propósitos de los usuarios de Wikipedia. La importancia de los autores puede variar según el campo: en las humanidades, donde el tema son a menudo experiencias y opiniones personales, quién es el autor de una fuente suele ser extremadamente importante; en las ciencias empíricas, donde el tema es a menudo datos y modelos impersonales, quién es el autor de una fuente es menos importante.
La propuesta ignora por completo tales diferencias entre campos de estudio. La propuesta afirma que el autor-fechaEl estilo existe porque se usa en artículos científicos y ensayos universitarios.
Esto esta mal . De hecho, los artículos científicos en muchos campos científicos no usan el estilo de fecha de autor . En los campos donde se usa el estilo de fecha de autor , es por una buena razón, a menudo relacionada con el beneficio de tener una lista de referencias que (típicamente) está ordenada por nombre de autor. Se puede alentar a los editores a evitar los peores problemas de legibilidad del estilo de fecha de autor sin una prohibición global de todas las citas de fecha de autor. En conclusión, esta es una propuesta terrible que malinterpreta el propósito de la diversidad de estilos de citas. Biogeographist ( charla ) 11:15, 6 de agosto de 2020 (UTC)- Biogeografista , por el comentario del Capitán arriba, creo que la Psicoterapia no requeriría cambios, incluso si esta propuesta se aplicara retroactivamente. De hecho, parece querer un caso mínimo, en el que cualquier cosa que se parezca a [1] ("pequeños números de clic azules") está bien, y lo único que se desaprueba es algo que se parece a "(Smith 2019)". La psicoterapia tiene muchos pequeños números de clics azules. WhatamIdoing ( charla ) 22:39, 6 de agosto de 2020 (UTC)
- Bien, tomé mi cita de Talk: Psychotherapy fuera de contexto. Allí fue parte de un argumento de por qué el bot de alguien no debería quitar los nombres de los autores de las citas (si no recuerdo mal). Aquí apoya el argumento de que la propuesta ignora diferencias importantes entre campos de estudio que harían que la referencia a la fecha del autor sea más apropiada en algunos temas que en otros. Biogeographist ( charla ) 23:09, 6 de agosto de 2020 (UTC)
- Biogeografista , por el comentario del Capitán arriba, creo que la Psicoterapia no requeriría cambios, incluso si esta propuesta se aplicara retroactivamente. De hecho, parece querer un caso mínimo, en el que cualquier cosa que se parezca a [1] ("pequeños números de clic azules") está bien, y lo único que se desaprueba es algo que se parece a "(Smith 2019)". La psicoterapia tiene muchos pequeños números de clics azules. WhatamIdoing ( charla ) 22:39, 6 de agosto de 2020 (UTC)
- Sin embargo, me opongo , no me importaría si adoptamos las
citas de estilo como el estilo preferido, incluso hasta el punto de permitir a los editores refactorizar otros estilos para ese estilo, siempre que se pueda hacer de una manera muy cuidadosa (ciertamente no en un artículo que se está creando activamente, tal vez en algo como un artículo que no ha tenido una cita actualizada en más de un año o algo así). - Charla xaosflux 14:03, 6 de agosto de 2020 (UTC)
- Xaosflux escribió:
incluso hasta el punto de permitir a los editores refactorizar otros estilos
. WP: CITEVAR ya permite tal refactorización, cuando hay consenso. Y si existe una oposición bien razonada a dicha refactorización en un artículo en particular, entonces la refactorización no debería realizarse. Biogeographist ( charla ) 14:45, 6 de agosto de 2020 (UTC)- @ Biogeographist : básicamente estoy a favor de fortalecer eso, y prefiero que el estilo de nota al pie en línea sea "preferido", a la extensión que si un artículo se ha vuelto algo estable, cambiar a esa forma no debería requerir determinar primero un consenso de página. Sin embargo, solo mi opinión, - xaosflux Talk 16:17, 6 de agosto de 2020 (UTC)
- @ Xaosflux : Entonces, ¿es tu opinión que incluso las notas al pie de página abreviadas (estilo de fecha de autor dentro de las notas al pie: {{ sfn }}) son ilegítimas y deberían refactorizarse? Biogeographist ( charla ) 16:38, 6 de agosto de 2020 (UTC)
- @ Xaosflux y Biogeographist : A mi entender, {{ sfn }} NO se considera un estilo de cita entre paréntesis como se discute aquí (es decir, no está cubierto en Wikipedia: Referencia entre paréntesis ). No es algo de lo que podamos deshacernos de manera efectiva, en cualquier caso, porque está destinado a ser el método de referencia para citar números de página individuales en un trabajo con múltiples citas. Me opondría firmemente a descartar eso . - Elmidae ( charla · contribuciones ) 16:46, 6 de agosto de 2020 (UTC)
- ( editar conflicto ) @ Biogeographist : absolutamente no, no creo que ninguno de los estilos de referencia sea ilegítimo; solo que hay un beneficio en preferir uno. No me refiero tanto al estilo de marcado, solo a los resultados aquí también, con respecto a su mención de {{ sfn }}: en realidad ya da como resultado un resultado de estilo (el resultado de la invocación del módulo es un etiqueta de referencia). Un ejemplo de lo que estoy hablando serían las referencias en la paradoja de la lotería, por ejemplo. - Charla xaosflux 16:52, 6 de agosto de 2020 (UTC)
- Específicamente, en mi ejemplo de la paradoja de la lotería , creo que sería más beneficioso para el lector usar un estilo de referencia más integrado en los datos aquí, no es que haya nada malo con la referencia actual. Sigo con la intención de refactorizar este (como ya obtuve el visto bueno del autor principal) pero sigo sin llegar a hacerlo. - Charla xaosflux 16:56, 6 de agosto de 2020 (UTC)
- @ Elmidae y Xaosflux : Ver Wikipedia: Plantillas de citas § Ejemplos de referencia de Harvard y notas al pie de página abreviadas y Plantilla: Documentación de citas de Harvard , que agrupan las citas de Harvard (fecha del autor) y las notas al pie de página abreviadas. Wikipedia: referencias entre paréntesis § Los ejemplos enumeran la fonología irlandesa como un ejemplo de un artículo destacado que utiliza citas de la fecha del autor, y la fonología irlandesa utiliza una combinación de {{ Sfn }} además de {{ Harvcoltxt }} y {{ Harvcolnb }} en línea. . Wikipedia: referencias por fecha de autor y Wikipedia: redireccionamiento de referencias de Harvard a Wikipedia: referencias entre paréntesis . Por lo tanto, "Harvard", "fecha del autor" y "entre paréntesis" se refieren al mismo estilo de cita. Si está argumentando a favor de desaprobar la referencia a la fecha del autor, está argumentando a favor de desaprobar todas esas plantillas. Y el efecto es el mismo si está argumentando a favor de refactorizar todas las referencias de fecha de autor a notas al pie estándar después de que un artículo se estabilice. Biogeographist ( charla ) 17:05, 6 de agosto de 2020 (UTC)
- Todas esas plantillas invocan Module: Footnotes , por lo que ya están usando citas integradas en datos. ¿Viste el ejemplo al que me referí específicamente anteriormente que solo usa citas de texto libre? Eso es lo que creo que debería ser menos preferido (aunque es 100 veces mejor que no tener citas y, por lo tanto, no debería ser rechazado por los editores, especialmente aquellos a los que no les importa o no conocen otras formas). - Charla xaosflux 17:19, 6 de agosto de 2020 (UTC)
- @ Xaosflux : Vi tu ejemplo. Pero la propuesta aquí es desaprobar incluso la referencia de fecha de autor que invoca Módulo: Notas al pie : vea el ejemplo citado en la propuesta original, Actuario . Necesitamos algunos términos nuevos para diferenciar entre las referencias al autor y la fecha que invoca y no al Módulo: Notas al pie . Biogeographist ( charla ) 17:35, 6 de agosto de 2020 (UTC)
- @ Biogeographist : el proponente dice específicamente
Propongo que desaprovechemos formalmente el estilo de cita entre paréntesis.
- no dice solo los que usan ciertas plantillas de marcado. Mi sugerencia es que se debe preferir el uso de marcado y la sección de referencias automáticas en lugar de usar citas entre paréntesis de texto sin formato y secciones de referencias manuales de texto sin formato. - Charla xaosflux 17:47, 6 de agosto de 2020 (UTC)- Xaosflux escribió:
Mi sugerencia es que se debe preferir el uso de marcado y la sección de referencias automáticas a usar citas entre paréntesis de texto sin formato y secciones de referencias manuales de texto sin formato.
Por "marcado" supongo que te refieres a la referencia de la fecha del autor que invoca Module: Footnotes . Lo suficientemente justo. Eso es más específico que su voto! Anterior. También es más específico que la propuesta original anterior, que propone desaprobar todas las referencias de fecha de autor, ya sea que invoque o no el Módulo: Notas al pie . Biogeographist ( charla ) 17:56, 6 de agosto de 2020 (UTC)- @ Xaosflux : suelo utilizar {{ sfn }} cuando cito varias páginas de una o más fuentes, por ejemplo, Alphonse van Gèle . No abarrota el texto, ni para el editor ni para el lector, pero permite citas precisas sin tener que replicar la definición de fuente completa para cada página o sección citada. Me opondría firmemente a permitir que los editores cambien de estilo {{ sfn }} a sin discusión. Dicho esto, no veo la necesidad de utilizar estilos distintos de {{ sfn }} y , que se pueden mezclar en un artículo, ya sea con texto o {{ citation }} para formatear la definición de origen. Aymatth2 ( charla ) 00:59, 4 de septiembre de 2020 (UTC)
- Hola @ Aymatth2 : gracias por la nota, no tengo ningún problema con eso, ya que en realidad ya se está usando
, simplemente envuelto en otra plantilla. Por ejemplo, se
{{sfn|Smith|Jones|Brown|Black|2005|p=25}}
expande a[[#CITEREFSmithJonesBrownBlack2005|Smith et al. 2005]], p. 25.
. Lo único que sugiero es que apoyamos firmemente las referencias que se integran en el marcado de referencias sobre el formato pararenthicial de texto plano simple. - xaosflux Talk 01:24, 4 de septiembre de 2020 (UTC)
- Hola @ Aymatth2 : gracias por la nota, no tengo ningún problema con eso, ya que en realidad ya se está usando
- @ Xaosflux : suelo utilizar {{ sfn }} cuando cito varias páginas de una o más fuentes, por ejemplo, Alphonse van Gèle . No abarrota el texto, ni para el editor ni para el lector, pero permite citas precisas sin tener que replicar la definición de fuente completa para cada página o sección citada. Me opondría firmemente a permitir que los editores cambien de estilo {{ sfn }} a sin discusión. Dicho esto, no veo la necesidad de utilizar estilos distintos de {{ sfn }} y , que se pueden mezclar en un artículo, ya sea con texto o {{ citation }} para formatear la definición de origen. Aymatth2 ( charla ) 00:59, 4 de septiembre de 2020 (UTC)
- Xaosflux escribió:
- @ Biogeographist : el proponente dice específicamente
- @ Xaosflux : Vi tu ejemplo. Pero la propuesta aquí es desaprobar incluso la referencia de fecha de autor que invoca Módulo: Notas al pie : vea el ejemplo citado en la propuesta original, Actuario . Necesitamos algunos términos nuevos para diferenciar entre las referencias al autor y la fecha que invoca y no al Módulo: Notas al pie . Biogeographist ( charla ) 17:35, 6 de agosto de 2020 (UTC)
- Todas esas plantillas invocan Module: Footnotes , por lo que ya están usando citas integradas en datos. ¿Viste el ejemplo al que me referí específicamente anteriormente que solo usa citas de texto libre? Eso es lo que creo que debería ser menos preferido (aunque es 100 veces mejor que no tener citas y, por lo tanto, no debería ser rechazado por los editores, especialmente aquellos a los que no les importa o no conocen otras formas). - Charla xaosflux 17:19, 6 de agosto de 2020 (UTC)
- @ Elmidae y Xaosflux : Ver Wikipedia: Plantillas de citas § Ejemplos de referencia de Harvard y notas al pie de página abreviadas y Plantilla: Documentación de citas de Harvard , que agrupan las citas de Harvard (fecha del autor) y las notas al pie de página abreviadas. Wikipedia: referencias entre paréntesis § Los ejemplos enumeran la fonología irlandesa como un ejemplo de un artículo destacado que utiliza citas de la fecha del autor, y la fonología irlandesa utiliza una combinación de {{ Sfn }} además de {{ Harvcoltxt }} y {{ Harvcolnb }} en línea. . Wikipedia: referencias por fecha de autor y Wikipedia: redireccionamiento de referencias de Harvard a Wikipedia: referencias entre paréntesis . Por lo tanto, "Harvard", "fecha del autor" y "entre paréntesis" se refieren al mismo estilo de cita. Si está argumentando a favor de desaprobar la referencia a la fecha del autor, está argumentando a favor de desaprobar todas esas plantillas. Y el efecto es el mismo si está argumentando a favor de refactorizar todas las referencias de fecha de autor a notas al pie estándar después de que un artículo se estabilice. Biogeographist ( charla ) 17:05, 6 de agosto de 2020 (UTC)
- Específicamente, en mi ejemplo de la paradoja de la lotería , creo que sería más beneficioso para el lector usar un estilo de referencia más integrado en los datos aquí, no es que haya nada malo con la referencia actual. Sigo con la intención de refactorizar este (como ya obtuve el visto bueno del autor principal) pero sigo sin llegar a hacerlo. - Charla xaosflux 16:56, 6 de agosto de 2020 (UTC)
- @ Xaosflux : Entonces, ¿es tu opinión que incluso las notas al pie de página abreviadas (estilo de fecha de autor dentro de las notas al pie: {{ sfn }}) son ilegítimas y deberían refactorizarse? Biogeographist ( charla ) 16:38, 6 de agosto de 2020 (UTC)
- @ Biogeographist : básicamente estoy a favor de fortalecer eso, y prefiero que el estilo de nota al pie en línea sea "preferido", a la extensión que si un artículo se ha vuelto algo estable, cambiar a esa forma no debería requerir determinar primero un consenso de página. Sin embargo, solo mi opinión, - xaosflux Talk 16:17, 6 de agosto de 2020 (UTC)
- Xaosflux escribió:
- Fuerte apoyo . El objetivo de una referencia es transmitir información. No hay una ventaja fundamental de un estilo sobre el otro, por lo que tener una proliferación de estilos solo dificulta que las herramientas administren los datos. - RoySmith (charla) 16:00, 6 de agosto de 2020 (UTC)
- RoySmith escribió:
No hay una ventaja fundamental de un estilo sobre el otro,
pero mencioné una gran ventaja de los estilos de fecha de autor y citas cortas arriba. Otras ventajas se enumeran en Referencia entre paréntesis § Ventajas . Biogeographist ( charla ) 16:38, 6 de agosto de 2020 (UTC)- Biogeografista , supongo que te refieres a
Un beneficio importante de los estilos de fecha de autor y citas cortas es que la lista de referencias se ordena (típicamente) por nombre de autor, lo cual es extremadamente útil en campos como las humanidades y algunos estudios sociales donde los nombres de los autores son especialmente importantes.
Creo que no entendiste el punto. La forma en que se ordena una lista es cuestión de presentación. Si los datos subyacentes estuvieran almacenados en un formato uniforme y analizable por máquina, sería trivial crear una herramienta que clasificara las referencias de la forma deseada. - RoySmith (charla) 17:16, 6 de agosto de 2020 (UTC)- @ RoySmith : Ah, ya veo. Tienes razón, me perdí el punto. ¿Tu herramienta ya existe o es hipotética? ¡Es mejor crear la herramienta primero antes de prohibir las referencias a la fecha del autor! Tenemos que ver qué tan bien funciona su herramienta antes de decidir usarla en su lugar. Biogeographist ( charla ) 17:35, 6 de agosto de 2020 (UTC)
- Biogeografista , supongo que te refieres a
- RoySmith escribió:
- Fuerte apoyo . Más de una vez me he encontrado con un artículo con citas entre paréntesis como (Smith 2008) en el texto y ningún otro referente en el artículo que indique quién es "Smith" o qué escribió esa persona en 2008. Este tipo de error se hace posible cuando En primer lugar, se permite que los elementos de información se separen, de modo que el editor que escribe el contenido puede olvidarse incluso de incluir la cita a la que se hace referencia, u otro editor que reutiliza un fragmento de contenido puede olvidarse de transferirlo. BD2412 T 16:25, 6 de agosto de 2020 (UTC)
- Las desventajas que mencionó BD2412 también ocurren con las etiquetas de referencia: más de una vez me he encontrado con etiquetas de referencia duplicadas o etiquetas de referencia con información de citas incompleta. Los editores negligentes no son una buena razón para prohibir globalmente las citas de la fecha del autor, ya que los editores pueden ser igualmente negligentes con las etiquetas de referencia. Biogeographist ( charla ) 16:38, 6 de agosto de 2020 (UTC)
- Las etiquetas de referencia se pueden rescatar. Los paréntesis para los que nunca se agrega la cita correspondiente no pueden. BD2412 T 17:45, 6 de agosto de 2020 (UTC)
- Estoy bastante seguro de que he tenido que eliminar las etiquetas de referencia irrecuperables más de una vez. No hay diferencia. En ambos casos, es una falta de información suficiente lo que impide la verificabilidad. Biogeographist ( charla ) 17:50, 6 de agosto de 2020 (UTC)
- El problema descrito por BD2412 puede ocurrir siempre que se utilice un sistema de citas abreviadas. No importa si son las citas entre paréntesis en línea discutidas aquí, o notas al pie de página abreviadas (como las producidas por el ubicuo {{ sfn }}). - Uanfala (conversación) 19:21, 17 de agosto de 2020 (UTC)
- Estoy bastante seguro de que he tenido que eliminar las etiquetas de referencia irrecuperables más de una vez. No hay diferencia. En ambos casos, es una falta de información suficiente lo que impide la verificabilidad. Biogeographist ( charla ) 17:50, 6 de agosto de 2020 (UTC)
- Las etiquetas de referencia se pueden rescatar. Los paréntesis para los que nunca se agrega la cita correspondiente no pueden. BD2412 T 17:45, 6 de agosto de 2020 (UTC)
- Uanfala tiene razón, este problema no es causado por referencias entre paréntesis . Y el problema, por lo general, ni siquiera es tan difícil de solucionar. Por lo general, surge cuando un editor copia un texto de un artículo que usa referencias cortas en otro y se olvida de copiar las citas completas correspondientes. Por ejemplo, faltaban dos citas en la conjetura principal de la teoría de Iwasawa , y solo tomó unos segundos darse cuenta de que probablemente estaban en la teoría de Iwasawa , de la cual se había dividido el artículo. Problema resuelto. En los pocos casos en los que eso no funciona, una búsqueda en el texto fuente de la wiki generalmente lo encontrará. - NSH001 ( conversación ) 14:20, 18 de agosto de 2020 (UTC)
- Las desventajas que mencionó BD2412 también ocurren con las etiquetas de referencia: más de una vez me he encontrado con etiquetas de referencia duplicadas o etiquetas de referencia con información de citas incompleta. Los editores negligentes no son una buena razón para prohibir globalmente las citas de la fecha del autor, ya que los editores pueden ser igualmente negligentes con las etiquetas de referencia. Biogeographist ( charla ) 16:38, 6 de agosto de 2020 (UTC)
- Las referencias de comentarios se pueden anidar con la plantilla: refn . Esto puede preservar el estilo de las citas y reducir el desorden. - Emir de Wikipedia ( charla ) 16:56, 6 de agosto de 2020 (UTC) ( responda, gracias!)
{{reply to}}
- @ Emir de Wikipedia : No veo la relevancia de esta discusión. ¿Puede dar un ejemplo de cómo la anidación de referencias con {{ refn }} se aplica a la referencia de fecha de autor? Biogeographist ( charla ) 17:10, 6 de agosto de 2020 (UTC)
- Biogeographist , un ejemplo es la primera referencia en esta edición . Las citas entre paréntesis se conservarían en la lista de referencias, pero no saturarían el artículo. Emir de Wikipedia ( charla ) 17:15, 6 de agosto de 2020 (UTC)
- @ Emir de Wikipedia : Gracias. Su edición es básicamente una nota a pie de página abreviada . Las notas a pie de página abreviadas se utilizan, por ejemplo, en fonología irlandesa que se enumera en Wikipedia: Referencia entre paréntesis § Ejemplos como un ejemplo de un artículo destacado que utiliza citas de la fecha del autor. Es curioso que la edición de ejemplo que eligió estuviera en Actuario , ya que acabo de proponer convertir ese artículo en notas al pie abreviadas: consulte Charla: Actuario § propuesta de notas al pie abreviadas , agosto de 2020 . Biogeographist ( charla ) 17:35, 6 de agosto de 2020 (UTC)
- La propuesta no dice que las citas entre paréntesis abreviadas estén bien dentro de las notas a pie de página. Solo dice que deben quedar obsoletos en general, dondequiera que aparezcan. Por lo tanto, esta sugerencia no cumple con la desaprobación propuesta. - David Eppstein ( charla ) 19:13, 6 de agosto de 2020 (UTC)
- David Eppstein , Eso no es lo que quise decir con la propuesta, y lamento que se haya malinterpretado. Como sugiere el artículo de Actuary , mi problema fue solo con los paréntesis que no son notas al pie de página. Estoy perfectamente de acuerdo con sfn, y creo que convertir los paréntesis existentes en sfn es una de las soluciones ideales aquí. CaptainEek edita Ho Cap'n! ⚓ 19:23, 6 de agosto de 2020 (UTC)
- Las propuestas que se promulgan dentro de Wikipedia MOS y las pautas a menudo resultan ser interpretadas por editores obstinados y gnomos que insisten en que la redacción real de la propuesta, y no su intención original, debe cumplirse rígidamente en toda la enciclopedia. Entonces, si esa interpretación no es lo que pretendía, entonces su propuesta es defectuosa y debe corregirse antes de que rompamos accidentalmente muchos artículos a los que se hace referencia correctamente al forzar sus referencias a un formato más restringido que no puede adaptarse a la flexibilidad requerida para citas cortas. o lo que sea. - David Eppstein ( charla ) 19:41, 6 de agosto de 2020 (UTC)
- A riesgo de repetir lo que ya dije anteriormente, estoy de acuerdo en que se trata de una propuesta terriblemente formulada. Wikipedia: las referencias entre paréntesis cubren una variedad de variantes. Soy más comprensivo con CaptainEek nueva 's primera enmienda que permite {{ SFN }} y {{ harv }} variantes en las notas, pero no estoy de acuerdo con la nueva segunda enmienda que prohibiría incluso muy de vez en cuando en el texto { { harvtxt }} referencias (p. ej., " Eek (2020)Fonología irlandesa para ver un artículo destacado que mezcla de manera sensata referencias ocasionales de {{ harvtxt }} en el texto con notas al pie de página abreviadas. Es perfectamente legible, al menos tan legible como se puede esperar de un artículo sobre fonología be. Biogeographist ( charla ) 21:07, 6 de agosto de 2020 (UTC) propuesto ") en artículos que ya usan notas al pie de página abreviadas . Esa segunda enmienda me parece irrazonable, ya que permitir referencias ocasionales a {{ harvtxt }} en el texto en artículos que ya usan notas al pie de página abreviadas no evita las referencias con hipervínculos ni impide la legibilidad, que eran las propuestas originales razones expuestas para desaprobar las citas de la fecha del autor. Consulte
- Las propuestas que se promulgan dentro de Wikipedia MOS y las pautas a menudo resultan ser interpretadas por editores obstinados y gnomos que insisten en que la redacción real de la propuesta, y no su intención original, debe cumplirse rígidamente en toda la enciclopedia. Entonces, si esa interpretación no es lo que pretendía, entonces su propuesta es defectuosa y debe corregirse antes de que rompamos accidentalmente muchos artículos a los que se hace referencia correctamente al forzar sus referencias a un formato más restringido que no puede adaptarse a la flexibilidad requerida para citas cortas. o lo que sea. - David Eppstein ( charla ) 19:41, 6 de agosto de 2020 (UTC)
- David Eppstein , Eso no es lo que quise decir con la propuesta, y lamento que se haya malinterpretado. Como sugiere el artículo de Actuary , mi problema fue solo con los paréntesis que no son notas al pie de página. Estoy perfectamente de acuerdo con sfn, y creo que convertir los paréntesis existentes en sfn es una de las soluciones ideales aquí. CaptainEek edita Ho Cap'n! ⚓ 19:23, 6 de agosto de 2020 (UTC)
- La propuesta no dice que las citas entre paréntesis abreviadas estén bien dentro de las notas a pie de página. Solo dice que deben quedar obsoletos en general, dondequiera que aparezcan. Por lo tanto, esta sugerencia no cumple con la desaprobación propuesta. - David Eppstein ( charla ) 19:13, 6 de agosto de 2020 (UTC)
- @ Emir de Wikipedia : Gracias. Su edición es básicamente una nota a pie de página abreviada . Las notas a pie de página abreviadas se utilizan, por ejemplo, en fonología irlandesa que se enumera en Wikipedia: Referencia entre paréntesis § Ejemplos como un ejemplo de un artículo destacado que utiliza citas de la fecha del autor. Es curioso que la edición de ejemplo que eligió estuviera en Actuario , ya que acabo de proponer convertir ese artículo en notas al pie abreviadas: consulte Charla: Actuario § propuesta de notas al pie abreviadas , agosto de 2020 . Biogeographist ( charla ) 17:35, 6 de agosto de 2020 (UTC)
- Biogeographist , un ejemplo es la primera referencia en esta edición . Las citas entre paréntesis se conservarían en la lista de referencias, pero no saturarían el artículo. Emir de Wikipedia ( charla ) 17:15, 6 de agosto de 2020 (UTC)
- @ Emir de Wikipedia : No veo la relevancia de esta discusión. ¿Puede dar un ejemplo de cómo la anidación de referencias con {{ refn }} se aplica a la referencia de fecha de autor? Biogeographist ( charla ) 17:10, 6 de agosto de 2020 (UTC)
- Opongo deprecating el estilo del todo, pero sí más bien como la propuesta de xaosflux encima de hacer que el
estilo de citación al estilo Wikipedia "preferido" (incluyendo las plantillas que generan tales marcas). Personalmente, también prefiero el estilo de la nota al pie, pero según Wugapodes anterior, ya hacemos la vida lo suficientemente difícil para los nuevos editores, y aunque aprecio el argumento de que, en última instancia, estamos sirviendo al lector, creo que estaríamos sobrecargando innecesariamente a los nuevos editores incluso con más reglas al tiempo que proporciona muy poco (aunque ciertamente positivo) beneficio general para el lector. Sin embargo, establecer un estilo preferido (pero no estrictamente aplicado) para las citas permite a los colaboradores proporcionar las citas adecuadas de cualquier manera que puedan, y otros pueden venir más tarde, después de que el artículo haya alcanzado cierta apariencia de estabilidad, para adaptarlas al estilo preferido. . C Thomas 3 ( charla ) 21:14, 6 de agosto de 2020 (UTC)
- Sin embargo, sería importante explícitamente afirman que el estilo de "preferido" no excluye las notas más cortas , como se aclara en CaptainEek nueva 's primera enmienda . Biogeographist ( charla ) 21:32, 6 de agosto de 2020 (UTC)
- @ Cthomas3 : para aclarar lo que hablé con @ Biogeographist : arriba, creo que deberíamos preferir referencias que usen etiquetas de referencia y secciones de referencia, pero no soy muy exigente con la forma en que lo hacemos (por ejemplo, a través de una etiqueta de referencia literal, a través de una plantilla de prácticamente cualquier estilo que incorpore la etiqueta de referencia, etc.), pero las citas entre paréntesis de texto sin formato literal deberían ser menos preferidas. - Charla xaosflux 13:42, 7 de agosto de 2020 (UTC)
- Xaosflux y Biogeographist , eso es a lo que estaba tratando de llegar cuando dije "incluyendo cualquier plantilla que genere dicho marcado". Estoy ahí contigo, no creo que necesitemos especificar exactamente cómo generamos las etiquetas, solo que cualquier cosa que las genere está perfectamente bien. Y ciertamente no quisiera excluir específicamente nada como notas al pie abreviadas. CITEVAR aún se aplicaría a cualquier estilo válido. C Thomas 3 ( charla ) 16:18, 7 de agosto de 2020 (UTC)
- @ Cthomas3 : para aclarar lo que hablé con @ Biogeographist : arriba, creo que deberíamos preferir referencias que usen etiquetas de referencia y secciones de referencia, pero no soy muy exigente con la forma en que lo hacemos (por ejemplo, a través de una etiqueta de referencia literal, a través de una plantilla de prácticamente cualquier estilo que incorpore la etiqueta de referencia, etc.), pero las citas entre paréntesis de texto sin formato literal deberían ser menos preferidas. - Charla xaosflux 13:42, 7 de agosto de 2020 (UTC)
- Sin embargo, sería importante explícitamente afirman que el estilo de "preferido" no excluye las notas más cortas , como se aclara en CaptainEek nueva 's primera enmienda . Biogeographist ( charla ) 21:32, 6 de agosto de 2020 (UTC)
- Fuerte apoyo - Esta mala interpretación de esta propuesta es increíble ya que se refiere tan claramente a citas entre paréntesis que están en el texto mismo; con suerte, las enmiendas de Eek lo han aclarado. El estilo utilizado en artículos como Fonología irlandesa y Battle of Red Cliffs simplemente hiere al lector y lo distrae del contenido, no hay mucho más que decir que eso. Algunas de estas razones para la oposición son igualmente desconcertantes, al lector promedio no le importará quién sea el autor, y arrojar eso en su cara no tiene sentido: la sección de Historia de la disciplina en este artículo es apenas legible. Si una declaración / idea es tan importante fundada o pensada por un académico específico, entonces un artículo bien escrito simplemente diría algo como: "John Smith sugirió que ...". También hay algunas suposiciones serias sobre algunos grupos imaginarios de editores que dejarán Wikipedia si se elimina su estilo de cita preferido (tenga en cuenta: un estilo de cita que no se usa comúnmente en la actualidad). Usé sfn y, a veces, harv anidado, pero no dejaría Wikipedia si se eliminara uno, quiero decir, ¿qué? Si es tan fácil que algo te saque de Wikipedia, entonces no tenía idea de cómo estás todavía aquí. Aza24 ( charla ) 21:49, 6 de agosto de 2020 (UTC)
- Aza24 escribió:
al lector medio no le importará quién sea el autor
. Esto puede ser cierto para la fonología irlandesa § Historia de la disciplina , por lo que estoy de acuerdo en que la sección puede exagerar. Cuando dije " referencias ocasionales en el texto {{ harvtxt }}" arriba, no quise decir en cada oración , más bien una vez por párrafo si es necesario o conveniente. Pero no es cierto que en todos los campos a todos los lectores promedio no les importen los autores. En los campos de las humanidades, como la filosofía, que son conversaciones intergeneracionales, importa mucho quién dijo qué y cuándo lo dijo, y la referencia a la fecha del autor con una lista de referencias ordenada por nombre de autor tiene sentido. Biogeographist ( charla ) 22:09, 6 de agosto de 2020 (UTC)- Me alegra ver que también soy interrogado por el mismo usuario que siente la necesidad de pasar por todos los puntos de vista opuestos y elegir todo lo que pueda con lo que no esté de acuerdo ... Pero lo siento, lo que está diciendo no tiene sentido. Cada estilo de cita dicta quién es el autor, cada uno de ellos , si un lector está tan inclinado a ver quién es el autor, todo lo que necesita es colocar el cursor sobre la referencia, así que realmente no tengo idea de a qué te refieres. Poner el nombre en la cita del texto no hace más que agregar distracción y confusión innecesarias. Parece que has ignorado por completo lo que dije sobre si el nombre es importante o la idea está intrínsecamente vinculada con un determinado individuo, entonces debería estar en el texto de todos modos, fuera de la cita, algo que ya es una práctica común para los artículos bien escritos. Aza24 ( charla ) 22:21, 6 de agosto de 2020 (UTC)
- No estoy en desacuerdo con tu afirmación de que
un artículo bien escrito simplemente diría algo como: "John Smith sugirió que ...",
así que no lo abordé. De hecho, así es como escribo normalmente. Estoy de acuerdo en que los artículos con notas a pie de página generalmente están mejor escritos. Pero no estoy de acuerdo en que todos los artículos con " referencias {{ harvtxt }} en el texto ocasionales" estén necesariamente mal escritos o sean lo suficientemente ilegibles como para justificar la desaprobación universal del estilo.Cada estilo de cita dicta quién es el autor
, como dijiste, pero no todos los estilos de cita clasifican la lista de referencias por autor. Hay más ventajas en ordenar la lista de referencias por autor de las que podría enumerar (como ver fácilmente de un vistazo qué obras de un autor se citan). Esto tiene mucho sentido para mí, pero si no lo tiene para usted, entonces puedo entender que apoyaría firmemente la propuesta. Y con respecto a tu comentario de que soy unusuario que siente la necesidad de pasar por todos los puntos de vista opuestos y elegir todo lo que pueda con lo
que no esté deacuerdo
, eso no es cierto: el comentario que está inmediatamente encima del suyo está en "mi lado" del debate, pero yo respondí a ese también porque tenía información para agregar. Y si pienso en información adicional que amplía la conversación, ¿por qué no debería agregarla? Biogeographist ( charla ) 23:09, 6 de agosto de 2020 (UTC)
- No estoy en desacuerdo con tu afirmación de que
- Me alegra ver que también soy interrogado por el mismo usuario que siente la necesidad de pasar por todos los puntos de vista opuestos y elegir todo lo que pueda con lo que no esté de acuerdo ... Pero lo siento, lo que está diciendo no tiene sentido. Cada estilo de cita dicta quién es el autor, cada uno de ellos , si un lector está tan inclinado a ver quién es el autor, todo lo que necesita es colocar el cursor sobre la referencia, así que realmente no tengo idea de a qué te refieres. Poner el nombre en la cita del texto no hace más que agregar distracción y confusión innecesarias. Parece que has ignorado por completo lo que dije sobre si el nombre es importante o la idea está intrínsecamente vinculada con un determinado individuo, entonces debería estar en el texto de todos modos, fuera de la cita, algo que ya es una práctica común para los artículos bien escritos. Aza24 ( charla ) 22:21, 6 de agosto de 2020 (UTC)
- Aza24 escribió:
- Apoyo : soy un psicólogo que evita el estilo APA siempre que es posible. Las citas entre paréntesis interrumpen el flujo del texto; requieren voltear hacia adelante y hacia atrás (imprimir) o escanear hacia adelante y hacia atrás; y el estilo permite referencias perezosas en las que el autor no tiene que especificar en qué parte de un documento encuentra apoyo para su argumento o declaración. Me doy cuenta de que esta propuesta no se trata del estilo APA per se. Simplemente deseo explicar mi apoyo para descargar la mayoría de las formas de citas entre paréntesis en la Wikipedia en inglés. // El "segundo tipo" de desaprobación parece preferible: "los editores pueden reemplazar esto a menos que haya un consenso específico en contra de hacerlo" (ver el astuto comentario de AntiCompositeNumber cerca del comienzo de esta sección). - Mark D Worthen PsyD (hablar) (Soy un hombre, los pronombres masculinos tradicionales están bien). 00:06, 7 de agosto de 2020 (UTC)
- Markworthen escribió:
el estilo permite referencias perezosas en las que el autor no tiene que especificar en qué parte de un documento encuentra apoyo para su argumento o declaración
. Este es un problema importante en muchos estudios de ciencias sociales, pero también puede ser un problema con las etiquetas de referencia estándar, de ahí la etiqueta {{ page required }}. Consulte Teoría de factores comunes para ver un ejemplo de un artículo en psicología, gran parte del cual escribí, que usa el estilo de la fecha del autor en notas al pie de página abreviadas con muchos números de página. Biogeographist ( charla ) 00:28, 7 de agosto de 2020 (UTC)- Excelentes puntos biogeógrafos . En este caso, Wikipedia requiere un mayor nivel de erudición cuando se trata de fuentes confiables que muchas revistas de psicología prominentes. // Por cierto, la teoría de los factores comunes es un muy buen artículo sobre un tema importante. - Mark D Worthen PsyD (hablar) (Soy un hombre; los pronombres masculinos tradicionales están bien). 00:00, 8 de agosto de 2020 (UTC)
- @ Markworthen : todos los estilos de referencia utilizados en el permiso de Wikipedia
referencias perezosas en las que el autor no tiene que especificar en qué parte de un documento encuentra apoyo para su argumento o declaración
; sea cual sea el estilo que use, no estoy obligado a ingresar un número de página, ni hay ningún tipo de advertencia o mensaje de error si lo olvido. Las referencias entre paréntesis no son diferentes a este respecto: además, no hay nada en ellas que obstaculice la provisión de un número de página. Se ha mencionado el artículo Actuario ; aquí, veo que algunas (pero de ninguna manera todas) de las referencias muestran explícitamente un número de página, por ejemplo (Trowbridge 1989, p. 7) al final del párrafo inicial. Cuando los números de página se omiten de las referencias entre paréntesis, es una fuente sin números de página (como una página web) o los números de página se proporcionan en la cita completa. - Red rose64 🌹 ( hablar ) 11:46, 8 de agosto de 2020 (UTC)- Redrose64 - Buen punto. Estaba hablando específicamente de mis frustraciones con el estilo APA, pero resaltas una diferencia importante entre los estilos formales (APA, Bluebook, Chicago, etc.) y Wikipedia. Sé que los editores a menudo piden números de página específicos para respaldar una declaración, por lo que hay al menos cierta conciencia sobre este tema. Pero, ¿cree que debemos poner más énfasis en la importancia de las citas de páginas específicas? - Mark D Worthen PsyD (hablar) (Soy un hombre, los pronombres masculinos tradicionales están bien). 02:38, 9 de agosto de 2020 (UTC)
- No estoy familiarizado con la APA ni con esos otros; diferentes instituciones académicas pueden establecer sus propias reglas y pueden prohibir el uso de números de página, no lo sé. Tengo un libro que recogí un día cuando estaba en Hertford College, Oxford, para una entrevista:
- Este libro muestra explícitamente cómo dar un número de página con una referencia entre paréntesis. Las instituciones académicas pueden requerir que sus estudiantes se adhieran a reglas particulares al presentar su trabajo, pero no estamos obligados de esa manera. Si la fuente los usa, es genial tener números de página (o similares), en interés de WP: V ; pero esa página (que es un documento de política de contenido central) los menciona solo una vez , en la oración (
Cite la fuente con claridad, idealmente dando el (los) número (s) de página, aunque a veces una sección, un capítulo u otra división puede ser apropiada en su lugar; consulte Wikipedia: Citando fuentes para obtener detalles sobre cómo hacer esto.
Además de WP: CITE , se trata con más detalle en Ayuda: Referencias y números de página ; y ambos incluyen secciones sobre referencias entre paréntesis que muestran cómo proporcionar números de página (consulte Wikipedia: fuentes de citas # Referencia entre paréntesis ; Ayuda: Referencias y números de página # Referencia entre paréntesis ) por lo que no es como si la práctica estuviera oculta o desalentada. aunque WP: V podría mejorar con respecto a los números de página en general. - Mi punto es que oponerse a un estilo entre paréntesis sobre la base de que a veces puede usarse sin números de página es un argumento falaz. Todavía tengo que encontrar un estilo de referencia utilizado en Wikipedia que prohíba o desaconseje el uso de números de página, aparte del método obsoleto WP: CS: EMBED . - Red rose64 🌹 ( charla ) 14:17, 9 de agosto de 2020 (UTC)
- Redrose64 - Buen punto. Estaba hablando específicamente de mis frustraciones con el estilo APA, pero resaltas una diferencia importante entre los estilos formales (APA, Bluebook, Chicago, etc.) y Wikipedia. Sé que los editores a menudo piden números de página específicos para respaldar una declaración, por lo que hay al menos cierta conciencia sobre este tema. Pero, ¿cree que debemos poner más énfasis en la importancia de las citas de páginas específicas? - Mark D Worthen PsyD (hablar) (Soy un hombre, los pronombres masculinos tradicionales están bien). 02:38, 9 de agosto de 2020 (UTC)
- Markworthen escribió:
- Apoye el "segundo tipo" de desaprobación, es decir, "los editores pueden reemplazar esto a menos que haya un consenso específico en contra de hacerlo". Hay buenos usos de las citas entre paréntesis en prosa, especialmente para usos impresos, y hay editores de Wikipedia como yo que usan citas entre paréntesis en la vida real. Pero en Wikipedia, que está principalmente en línea, esto es bastante difícil de manejar y relativamente rara vez se usa a favor de notas al pie (usando
etiquetas) y una lista de referencias. Tener citas entre paréntesis en la prosa puede ser una distracción e inútil, ya que no hay una lista de notas al pie (o una reducida) en este formato. Incluso las plantillas de estilo {{ sfn }} y {{ harv }} de las notas al pie son más fáciles de comprender.
Entiendo que hay personas que se sienten cómodas con las referencias entre paréntesis y que algunas personas seguirán oponiéndose a esta propuesta. Sin embargo, hay mejores formas de hacer referencia en Wikipedia, en particular notas al pie. Al final, se supone que este tipo de referencias transmiten información al lector, pero la experiencia del lector puede verse obstaculizada al poner las citas entre paréntesis en la prosa, en lugar de entre paréntesis pequeños y relativamente inoportunos. epicgenius ( charla ) 01:08, 7 de agosto de 2020 (UTC)- @ Epicgenius : para que quede claro, ¿apoya una propuesta diferente a la que estamos discutiendo, una que solo se aplica a las citas entre paréntesis en prosa que están pensadas puramente como una referencia y no como parte del texto del artículo? ¿O apoya la propuesta que estamos discutiendo que, incluso después de dos niveles de intento de aclaración, todavía se aplica explícitamente a ejemplos como el enlace de fonología irlandesa anterior, donde el texto principal del artículo analiza la autoría de las publicaciones? Si es lo último, ¿qué circunloquios para discutir la autoría en el texto le parecerían alternativas aceptables y por qué? - David Eppstein ( charla ) 01:24, 7 de agosto de 2020 (UTC)
- David Eppstein , estoy respondiendo a lo que dijo CaptainEek en su primera aclaración:
El único objetivo es lograr que en lugar de ver Ipsum lorem facto (Eek, 2020), terminemos con Ipsum lorem facto con un pequeño número de referencia azul al final, lo que lleva a una nota al pie que todavía puede decir "(Eek , 2020) ".
Apoyo la propuesta a la que parecen estar respondiendo todos los demás comentarios. En cuanto al enlace fonológico irlandés, se trataría como una discusión de trabajo académico en lugar de ejemplos de citas entre paréntesis (p. Ej.Alguna declaración se menciona en Scholar (2020).
Opuesto aAlguna declaración. (Becario 2020)
. No sería necesario convertirlos en notas al pie y no apoyaría cambiar esto si ya está en el artículo. epicgenius ( charla ) 14:31, 7 de agosto de 2020 (UTC)
- David Eppstein , estoy respondiendo a lo que dijo CaptainEek en su primera aclaración:
- @ Epicgenius : para que quede claro, ¿apoya una propuesta diferente a la que estamos discutiendo, una que solo se aplica a las citas entre paréntesis en prosa que están pensadas puramente como una referencia y no como parte del texto del artículo? ¿O apoya la propuesta que estamos discutiendo que, incluso después de dos niveles de intento de aclaración, todavía se aplica explícitamente a ejemplos como el enlace de fonología irlandesa anterior, donde el texto principal del artículo analiza la autoría de las publicaciones? Si es lo último, ¿qué circunloquios para discutir la autoría en el texto le parecerían alternativas aceptables y por qué? - David Eppstein ( charla ) 01:24, 7 de agosto de 2020 (UTC)
- Acepte artículos que indiquen su origen de cualquier manera. Apoye formalmente permitiendo y alentando la conversión de citas de texto sin formato a citas . Actualice WP: Parenthetical_referencing para indicar que es adecuado si se usa, pero que puede y debe actualizarse a una referencia adecuada. Alsee ( charla ) 02:50, 7 de agosto de 2020 (UTC)
- Apoyo : mi opinión sería diferente (permitir que el sistema coexista con los demás) si no hubiera encontrado cierta terquedad por parte de los adherentes al sistema para aferrarme a él donde realmente no es adecuado ( ejemplo ). Wikipedia tiene como objetivo un amplio número de lectores (tanto académicos como no académicos). En los estudios académicos, las referencias por notas numeradas se utilizan en todas las disciplinas: ningún estudioso tiene ninguna dificultad para comprender este sistema de referencia (incluso cuando escribe sobre temas filosóficos, etc.). Para lectores amplios fuera de la academia, las notas a pie de página numeradas son mucho más fáciles de digerir. Así que adoptar un escenario de desvanecimiento me parece perfectamente aceptable. En un primer paso, WP: CITEVAR podría actualizarse diciendo que depende del proponente de las referencias de Harvard que ese sistema de referencia se use más comúnmente en fuentes confiables al escribir sobre el tema del artículo. Todos los demás artículos, cuando eso no se pueda demostrar, pueden ser transformados en notas al pie de página numeradas por los editores que deseen hacerlo. Sin embargo, supongo que tales transformaciones nunca deberían ser operadas por bot, aunque probablemente sean demasiado contraproducentes (demasiado propensas a errores: una reparación por bot puede introducir más problemas de los que resuelve). - Francis Schonken ( charla ) 08:03, 7 de agosto de 2020 (UTC)
- Apoyo Apoyo para desaprobar las citas entre paréntesis como (Smith 2020) en nuevos artículos y también apoyo la conversión de artículos existentes en un estilo usando índices en los que se puede hacer clic como [1] , no en un movimiento de masa de fuerza bruta que lo golpea en todos los artículos sin importar qué , pero aplicando el buen sentido común: si un editor siente la necesidad de convertir un artículo, no se le debe impedir que lo haga, a menos que haya un consenso claro (basado en buenas razones por las que ese es el estilo que se utilizará en una publicación). artículo, no solo mentalidad de bloqueo) para continuar usando citas entre paréntesis en ese artículo, o a menos que un editor que se aferre a las citas entre paréntesis esté todavía en el proceso de editar activamente un artículo (para que no esté confundido o desanimado) . Sin embargo, el valor predeterminado sin tal consenso debería ser permitir la conversión en lugar de descartarla por alguna extraña consecuencia de WP: CITEVAR . El progreso es importante para nosotros.
- Algunos editores han presentado el argumento de que nuestros estilos de citas son difíciles de entender para los nuevos editores y que no deben desanimarse de la edición porque necesitamos nuevos editores y, por lo tanto, deben usar el estilo al que estén acostumbrados. Eso está bien para mí hasta cierto punto, sin embargo, también se puede argumentar que los editores existentes (no) se desaniman a contribuir a los artículos que usan (distraen la lectura y no son funcionales) citas entre paréntesis:
- He tenido la experiencia de que algunos artículos (por lo general no muy bien desarrollados) son básicamente WP: propiedad de algunos editores que hacen cumplir las citas entre paréntesis sin agregar nada al artículo (más). Algunos de ellos alguna vez contribuyeron al artículo hace años, otros nunca agregaron nada, solo revertieron por el simple hecho de hacerlo, incluso si falta el artículo y las contribuciones trajeron adiciones importantes. Básicamente, estos editores están simplemente sentados bloqueando una parte significativa de los grados potenciales de desarrollo futuro de un artículo. Por lo tanto, mientras estos editores contribuyan activamente a un artículo, creo que deberían salirse con la suya por el mero hecho de hacerlo, pero al final, no estamos aquí para los viajes del ego sino para escribir una enciclopedia, y ya que los artículos nunca están completos y terminados, nuestra prioridad debe ser mejorar el contenido y la funcionalidad del artículo , no complacer a los editores. Además, mientras que las plantillas de citas CS1 / CS2 pueden ser difíciles de dominar (en particular algunos casos especiales esotéricos), usar la sintaxis básica de wiki ... es realmente fácil. Por lo tanto, si dichos editores no contribuyen a un artículo durante medio año o un año, la "cláusula del abuelo" debería expirar automáticamente, de modo que, en beneficio del artículo y del proyecto en su conjunto, otros editores también se sienten más animados a contribuir con sus cosas a dichos artículos.
- - Matthiaspaul ( charla ) 11:28, 7 de agosto de 2020 (UTC)
- Un fuerte apoyo al tener una diversidad de estilos de referencia no es bueno para el aspecto de Wikipedia. Este es un estilo difícil de usar, así que vamos a desaprobarlo. Podemos decir que un artículo destacado no debe contener este estilo de referencia. Graeme Bartlett ( charla ) 11:57, 7 de agosto de 2020 (UTC)
- Soporte según Alsee (aceptar y cambiar) y otros argumentos anteriores sobre el desorden de páginas y la legibilidad. · · · Peter Southwood (charla) : 14:20, 7 de agosto de 2020 (UTC)
- Soporte según Alsee. - Charla de Majavah · ediciones 15:19, 7 de agosto de 2020 (UTC)
- Oponerse a "Una consistencia tonta es el duende de las mentes pequeñas ..." . Andrew 🐉 ( charla ) 20:49, 7 de agosto de 2020 (UTC)
- Voy Apoyo por el principio de evitar / eliminar la complejidad innecesaria. La enciclopedia generalmente no se beneficia de múltiples métodos para lograr lo mismo. No he visto un argumento de Oppose que supere eso para mí. Me opongo a limitar esto (o prácticamente cualquier cosa) a los artículos nuevos, ya que la mayoría de los artículos de importancia real ya se han creado. - Mandruss ☎ 23:59, 7 de agosto de 2020 (UTC)
- Soporte - Debemos simplificar el sistema de referencia. Este es un buen pequeño paso. —¿Philoserf? ( charla ) 08:30, 8 de agosto de 2020 (UTC)
- Oponerse como el extremo delgado de la cuña, etc. No me gusta este sistema en absoluto, pero está muriendo de forma natural. Tampoco me gusta la promoción del horrible estilo sfn en la propuesta. Johnbod ( charla ) 13:04, 8 de agosto de 2020 (UTC)
- Apoyo provisional . Los argumentos de Wugapodes et al son completamente válidos, pero por lo que puedo ver, esta propuesta no rechazaría los artículos escritos con ese estilo, al igual que los artículos escritos completamente sin citas en línea no están actualmente rechazados. Nuestro software nos brinda la capacidad de vincular citas en línea con las entradas de la bibliografía correspondiente, y hacerlo mejora enormemente la accesibilidad. Dado eso, nuestras pautas de citas deben permitir a los editores cambiar a un formato que lo permita, sin tener que tomarse la molestia de tener que obtener un consenso primero. Tal como están las cosas, la preferencia del autor original por un estilo inaccesible tiene mucho peso, y eso es lo que creo que debe cambiar. Debemos evitar que este cambio se convierta en algo más para morder a los novatos . Vanamonde ( Discusión ) 16:04, 8 de agosto de 2020 (UTC)
- Las referencias entre paréntesis también se pueden vincular a las entradas de la bibliografía correspondiente, esto es lo que hace. - Red rose64 🌹 ( charla ) 16:39, 8 de agosto de 2020 (UTC)
{{harv}}
- @ Redrose64 : Hasta que lo diga explícitamente, voy a proceder con la creencia de que esta propuesta se refiere solo a lo que el profano describiría como referencias entre paréntesis, en lugar de la interpretación más amplia que usted y David Eppstein están proponiendo. En lo que a mí respecta, el formato sfn sigue siendo un formato de nota al pie, que tiene citas de la fecha del autor en las notas al pie; no está agregando fechas de autor al texto en sí. CaptainEek Si está proponiendo deshacerse de las citas de harv, debe hacerlo explícito. Si no es así, y no creo que lo sea, valdría la pena aclararlo también en la propuesta. Vanamonde ( Discusión ) 15:07, 9 de agosto de 2020 (UTC)
- Vanamonxe93 Tienes razón, me refiero a la interpretación estrecha. Como he aclarado en la parte superior, solo me refiero a citas en línea, no a las plantillas sfn / harv. El objetivo aquí es hacer pequeños números azules, no destruir todas las citas entre paréntesis. CaptainEek edita Ho Cap'n! ⚓ 19:06, 9 de agosto de 2020 (UTC)
- ( Editar conflicto ) No estoy sugiriendo eso y son lo mismo, no lo son, aunque el método que usan para vincular a la entrada de bibliografía correspondiente es el mismo. Tampoco propongo que nos deshagamos de nada . Estoy señalando una falacia, es decir, la afirmación de que algunos han hecho que las referencias entre paréntesis no pueden vincularse a las entradas de la bibliografía correspondiente cuando se puede demostrar que sí . Usando Actuary como ejemplo, mire la sección principal: hay diez referencias entre paréntesis en la sección principal, y cada una de ellas tiene un enlace a la entrada de bibliografía correspondiente. Haga clic en el que desee: todos funcionan. - Red rose64 🌹 ( charla ) 19:12, 9 de agosto de 2020 (UTC)
{{sfn}}
{{harv}}
- @ Redrose64 : Bien, ese es un buen punto, pero ¿cuántos artículos con citas entre paréntesis usan esa sintaxis? Además, con respecto a ese artículo, diría que el desorden agregado sigue siendo una preocupación sustancial; y como mínimo, necesitamos darles a los editores la capacidad de agregar esa sintaxis a un artículo que usa citas entre paréntesis sin formato, lo cual también está prohibido actualmente por CITEVAR sin un ejercicio de construcción de consenso. Vanamonde ( Discusión ) 16:06, 10 de agosto de 2020 (UTC)
- Casi siete mil . - Red rose64 🌹 ( charla ) 17:49, 10 de agosto de 2020 (UTC)
- @ Redrose64 : Bien, ese es un buen punto, pero ¿cuántos artículos con citas entre paréntesis usan esa sintaxis? Además, con respecto a ese artículo, diría que el desorden agregado sigue siendo una preocupación sustancial; y como mínimo, necesitamos darles a los editores la capacidad de agregar esa sintaxis a un artículo que usa citas entre paréntesis sin formato, lo cual también está prohibido actualmente por CITEVAR sin un ejercicio de construcción de consenso. Vanamonde ( Discusión ) 16:06, 10 de agosto de 2020 (UTC)
- ( Editar conflicto ) No estoy sugiriendo eso y son lo mismo, no lo son, aunque el método que usan para vincular a la entrada de bibliografía correspondiente es el mismo. Tampoco propongo que nos deshagamos de nada . Estoy señalando una falacia, es decir, la afirmación de que algunos han hecho que las referencias entre paréntesis no pueden vincularse a las entradas de la bibliografía correspondiente cuando se puede demostrar que sí . Usando Actuary como ejemplo, mire la sección principal: hay diez referencias entre paréntesis en la sección principal, y cada una de ellas tiene un enlace a la entrada de bibliografía correspondiente. Haga clic en el que desee: todos funcionan. - Red rose64 🌹 ( charla ) 19:12, 9 de agosto de 2020 (UTC)
- Las referencias entre paréntesis también se pueden vincular a las entradas de la bibliografía correspondiente, esto es lo que hace. - Red rose64 🌹 ( charla ) 16:39, 8 de agosto de 2020 (UTC)
- Soporte por nominador. - Slade ☯ 10:00, 2 de septiembre de 2020 (UTC)
- Soporte por nom. No hay razón para usar un formato de referencia kludgy cuando tenemos herramientas que manejan las cosas mucho mejor y mejoran la experiencia de lectura para los usuarios habituales de Wikipedia. ···日本 穣·投稿· Habla con Nihonjoe · ¡ Únete a WP Japan ! 23:49, 2 de septiembre de 2020 (UTC)
- Soporte por nom. este proyecto es una enciclopedia, no un artículo. Clone commando sev ( hablar ) 00:06, 3 de septiembre de 2020 (UTC)
- Soporte : no se trata de una enciclopedia impresa ni de un trabajo de investigación universitario escrito a doble espacio en una IBM Selectric con montones de Wite-Out . Es hora de abandonar los errores y adoptar la accesibilidad, la usabilidad y el hipertexto. - MrX 🖋 12:09, 3 de septiembre de 2020 (UTC)
- Soporte por nom. Anonimu ( charla ) 17:21, 3 de septiembre de 2020 (UTC)
- Apoye la parte de "alejarse de". Si alguien usara citas en línea, no creo que sus contribuciones deban eliminarse automáticamente, pero tal vez este tipo de artículos podrían simplemente etiquetarse con un aviso de "limpieza de citas". Algo como eso. A fin de cuentas, me encantaría ver que todos los artículos de Wikipedia usen el mismo estilo de cita, en aras de la coherencia .-- Gen. Quon (Charla) 19:00, 3 de septiembre de 2020 (UTC)
Descanso arbitrario 1 (citas)
- Enérgicamente se oponen a David Eppstein y DGG. Además, apoyo la posición anterior de xaosflux de adoptar las
citas de estilo como el estilo preferido; sin embargo, sin menospreciar las citas parantéticas. 0qd ( charla ) 18:08, 8 de agosto de 2020 (UTC)
- Soporte para una opción diferente Veo cierto soporte para la desaprobación de esta opción en el futuro mientras se dejan los artículos existentes y los cambios que usan este formato. Voy a sugerir exactamente lo contrario. Esto está inspirado en @ Wugapodes : soporte para permitir que los nuevos editores adopten una variedad de estilos (ya es bastante difícil comenzar a editar sin imponer un estilo de referencia potencialmente nuevo; por qué no dejarles hacer algo que ya saben), así como la observación. que permitir múltiples estilos es discordante para el lector. Según WP: CITEVAR , desaconsejamos correctamente varios estilos dentro de un artículo (lo que significa que si un editor nuevo en una edición quiere trabajar en un artículo existente en lugar de en un artículo nuevo, necesita aprender el estilo) , pero es un poco menos discordante ver diferentes estilos de un artículo a otro.
- Deberíamos:
- Elige un estilo de casa
- Permita que los nuevos editores usen cualquier estilo que funcione
- Tarea un bot para hacer la conversión al estilo de la casa
- Se permiten excepciones cuando se justifica (no pretendo haber examinado todos los estilos de citas, y podría haber una buena razón para un estilo diferente en algún artículo o en alguna clase especial de artículos). - S Philbrick (Discusión) 18:09, 8 de agosto de 2020 (UTC)
- @ Sphilbrick : Aunque en general me gusta tu idea, te advierto que conseguir que un bot interprete las citas de forma libre sería extremadamente difícil, si no imposible. Especialmente si estás hablando de artículos creados por usuarios que no están familiarizados con Wikipedia, será un lío de diferentes campos en diferentes partes, algunos enlaces desnudos aleatorios, etc. Traté de escribir un analizador de citas una vez y fallé; Las herramientas existentes como AnyStyle son más para citas académicas formateadas de manera consistente que las cosas que se encuentran en Wikipedia. Vahurzpu ( charla ) 18:48, 8 de agosto de 2020 (UTC)
- Vahurzpu , no me sorprenderá en absoluto descubrir que algunos estilos, o peor aún, los enlaces desnudos no son aptos para la conversión de bots. Si escribimos el bot con cuidado, tendremos cuidado de no forzar un estilo en algo que no lo admita, y dejamos que los humanos lo aborden. No pretendo que mi propuesta resuelva todos los problemas de citas, pero creo que es un paso en la dirección correcta .-- S Philbrick (Charla) 18:54, 8 de agosto de 2020 (UTC)
- Esta propuesta deliberadamente no era la vida, el universo y todo . Si está interesado en seguir el suyo, sugeriría algo de tiempo WP: VPI o WT: CITE para dar forma a cómo cree que funcionaría esto. Sé que he visto un apoyo ligero a la idea de que deberíamos establecer un estilo de cita de la casa, pero no sé si 'ligero' es realmente suficiente para obtener un 'visto bueno de VPPRO' para ello .-- Izno ( hablar ) 23:26, 9 de agosto de 2020 (UTC)
- Deberíamos:
- Apoye la propuesta, que está dirigida al objetivo beneficioso de reducir el desorden en la prosa. La legibilidad es importante, e incluso para las referencias numeradas, tenemos cuidado con el desorden . Las preocupaciones planteadas se relacionan principalmente con interpretaciones y redacciones específicas que pueden discutirse una vez que se establece el principio previsto del asunto. No estoy de acuerdo en que este cambio desanime a los nuevos usuarios, dado que esencialmente está proponiendo usar el estilo que quieran, pero poniendo alrededor (en lugar de la mala interpretación de que estandarizará un formato de referencia particular). Agregar dos etiquetas cortas no es ni remotamente un obstáculo equivalente a aprender un nuevo estilo de cita. Es mucho menos oneroso que pedir a los usuarios que completen las URL desnudas, que es una práctica común y esperada. Además, sospecho que casi todos los que usan ese estilo de citas en otros trabajos se habrán enfrentado a requisitos de formato de citas mucho más onerosos y molestos. Este cambio presumiblemente sería un problema de MOS, más que una cuestión de política estricta, por lo que no sería algo por lo que los nuevos artículos sean rechazados, o que los editores sean mordidos, más que cualquier otra parte de MOS. CMD ( charla ) 19:25, 8 de agosto de 2020 (UTC)
- Um ... la gente es mordida por problemas de MOS. Blueboar ( charla ) 19:40, 8 de agosto de 2020 (UTC)
- Sí, y no creo que esta propuesta agrave ese problema como se ha sugerido. CMD ( charla ) 16:58, 9 de agosto de 2020 (UTC)
- Um ... la gente es mordida por problemas de MOS. Blueboar ( charla ) 19:40, 8 de agosto de 2020 (UTC)
- Opuesto . Esta es otra propuesta que tiene el potencial de desanimar a los contribuyentes productivos en nombre de la coherencia y uniformidad. Es posible que terminemos con un número limitado de editores que intentan controlar pero no logran hacer crecer y mantener toda la Wikipedia. Con menos editores viendo artículos, fácilmente podríamos sentirnos abrumados por el vandalismo. - Robert.Allen ( charla ) 19:29, 8 de agosto de 2020 (UTC)
- Fuerte oposición . Las citas entre paréntesis son un estilo excelente cuando se usan con notas explicativas al pie de página. Si bien es posible mezclar notas explicativas a pie de página con notas a pie de página de citas, es mucho más limpio tener citas y explicaciones claramente distintas.
Eso significa que las citas entre paréntesis son especialmente buenas para artículos muy técnicos, donde es más probable que sean útiles las notas explicativas al pie de página. No deberíamos intentar calzar todos los artículos en un solo estilo, cuando las consideraciones basadas en temas pueden favorecer a uno u otro. - Trovatore ( charla ) 19:39, 8 de agosto de 2020 (UTC) - Admite la segunda opción (es decir, "los editores pueden reemplazar esto a menos que haya un consenso específico en contra de hacerlo"). Mirando al actuario : puaj. Es terrible. De manera inequívoca. El hecho de que todavía se le permita existir como FA en 2020 es un excelente ejemplo de cómo Wikipedia a menudo se resiste demasiado al cambio.
- Para ser un poco más específico, no estoy convencido de que haya algo mejor en las citas entre paréntesis para los lectores, incluso (como se argumentó anteriormente) para las materias de humanidades donde el autor es más importante: Aza24 envió ese argumento. Y el punto de Markworthen acerca de que permiten citas más perezosas que introducen ambigüedad también es convincente.
- Con respecto a la compatibilidad con los principiantes (que creo que es de importancia crítica, como lo sabe cualquiera que esté familiarizado con mi trabajo de edición), los puntos de Wug me persuaden lo suficiente como para no apoyar la tercera opción, aunque solo a duras penas. Es importante tener en cuenta que existe una confusión adicional que se introduce para los principiantes al no tener un solo estilo de cita unificado, y el esfuerzo del editor dedicado a mejorar la documentación para las citas entre paréntesis es un esfuerzo que estaría mejor dirigido a la documentación del Estilo de cita 1. Pero a fin de cuentas, creo que es un poco más fácil decirles que pueden citar como quieran. Sin embargo, esa no es una justificación lo suficientemente convincente como para superar todas las demás consideraciones. Con respecto a WP: BITE , nadie debería tener un artículo rechazado en AfC o eliminado en AfD porque usa un estilo de cita diferente, ya que se supone que AfC se trata únicamente de si un artículo sobreviviría en AfD, y en AfD WP: Eliminación no es limpieza . Y no veo a nadie indignado porque el artículo que escribieron tenía citas entre paréntesis convertidas en notas a pie de página. La mejor solución para no morder a los recién llegados es que los editores experimentados no muerdan a los recién llegados.
- Respecto a la importación, bajo la segunda opción, aún estaría permitida, ya que algo es mejor que nada. El punto aquí es reconocer formalmente que las citas entre paréntesis son inferiores, no eliminar en masa todo lo que las contiene. [ hipérbole ] La segunda opción sentará las bases para que más adelante, una vez que nuestras principales herramientas de citas hayan sido mejoradas, apliquemos una forma más fuerte de desaprobación.
- Por último, a los que sostienen que este
vuela en la cara de WP: CITEVAR
, lo encuentro absolutamente poco convincente. No hay nada sagrado en las pautas establecidas hace una década, ya que WP: Consensus puede cambiar . Y en este caso, debería. {{u | Sdkb }} charla 19:50, 8 de agosto de 2020 (UTC)
- Apoyo débil , en la medida en que deberíamos desalentar el estilo a favor de referencias en línea: es demasiado prolijo, no indica números de página, etc., y en una discusión de FA o GA, apoyaría preguntar o incluso exigir a los autores que aléjate de él. Sin embargo , por usuario: puntos de DGG y de otros, tenemos muchos, mucho más problemas con los artículos sin ninguna cita, e incluso un estilo deficiente de cita es varios órdenes de magnitud mejor que ninguna, no queremos Para tener algún conflicto sobre una cosa tan trivial, un riesgo de desanimar a un editor nuevo o moderadamente nuevo que de otra manera es productivo y que está usando este estilo, queremos aplaudir que estén usando cualquier cita. - GRuban ( conversación ) 21:11, 8 de agosto de 2020 (UTC)
- @ Gruban : Usted afirma
es demasiado prolijo
- Autor, año y página: ¿cómo es esto más prolijo que cualquier otro estilo? Además, reclamasno indica números de página
, por supuesto que puede. Ver WP: PAREN # Cita en línea en el cuerpo del artículo , sexto punto; WP: PAREN # Números de página ; y WP: REFPAGE # Referencia entre paréntesis . - Red rose64 🌹 ( charla ) 14:38, 9 de agosto de 2020 (UTC)- @ Redrose64 : Porque está en línea. El ejemplo del Capitán Eek de Actuary en la parte superior de esta propuesta es un excelente ejemplo: la mitad del contenido está dedicado a las citas, lo que distrae al lector que está tratando de leer, en lugar de verificar. Necesitamos proporcionar verificaciones, pero nuestro objetivo principal es proporcionar contenido legible real, ¿verdad? El estilo de referencia en línea estándar habría sido siete números pequeños en superíndice que serían más fáciles de leer. Además, las citas entre paréntesis en línea deben repetirse cada vez que se usan, por lo que es un nombre y un año entre paréntesis cada vez o, si en realidad es mientras escribe, entonces un nombre, un año, dos puntos y una página. número, entre paréntesis cada vez, ¡incluso más! Nuevamente, como escribí, esto es secundario a tener citas, pero hacerlo de manera menos prolija en el contenido principal de nuestro artículo y guardar todos los detalles hasta el final es más legible. - GRuban ( charla ) 14:53, 9 de agosto de 2020 (UTC)
- @ Gruban : Usted afirma
- Soporte para el enfoque "preferido pero no requerido". Si un tema es notable, no deberíamos estar molestando a los novatos en AfC por el formato y demás, y no quisiera que esto se agregue. También Wugapodes hace un buen punto sobre el caso de uso de copiar y pegar.
Me gustaría que dijéramos que un editor es libre de actualizar las citas de texto sin formato a cualquier tipo de notas al pie vinculadas (incluidas sfn, referencias definidas por lista, etc.) sin necesidad de consultar cada vez, a menos que haya una referencia local. consenso en su contra. Actualmente CITEVAR'sdiferir al estilo utilizado por el primer colaborador importante
significa que el primer escritor gana. Eso podría cambiar. Y "actualizar" podría ser una buena forma de expresarlo.
No se trata solo de legibilidad, las referencias respaldadas por software brindan al lector comodidades adicionales, como mw: información sobre herramientas de referencia ; y otros han mencionado la detección programática de referencias.
Si necesita mencionar el autor y el año en el texto, y no quiere un "circunloquio" comoEn 2020, Pelagic et al. encontré que ...
, entonces iría tan lejos como para recomendar una construcción comoPelagic et al. (2020) encontró que ... [1]
- es decir, proporciona una referencia en la que se puede hacer clic además del "autor (año)". Para un artículo donde las referencias ya están en orden alfabético (o algún otro orden como la fecha), puede retenerlo a travésde referencias definidasporlista.
- Pelágico ( mensajes · Z ) - (18:48 dom 09, AEST) 08:48, 9 de agosto de 2020 (UTC)- Pelagic escribió:
Para un artículo donde las referencias ya están en orden alfabético (o algún otro orden como la fecha), puede retenerlo a través de referencias definidas por lista.
¿Es esto cierto? Nunca he visto referencias definidas por lista que muestren una lista de referencias (en el HTML renderizado final) en cualquier otro orden que no sea la secuencia de citas en el texto. Las referencias definidas por lista pueden estar en orden arbitrario en el marcado de la lista de referencias, pero no sé cómo hacer que la lista de referencias se muestre enorden alfabético (o algún otro orden como la fecha)
en el HTML renderizado final, por lo que siempre he usado la referencia de la fecha del autor para ese propósito. Biogeographist ( charla ) 13:20, 9 de agosto de 2020 (UTC)- Disculpas, @ Biogeographist , tienes razón. Estaba pensando en una situación en la que otro editor reordenó las referencias definidas por lista en un artículo en el que estaba trabajando, pero eso se debe a que las querían en orden alfabético en el código fuente, no en el resultado renderizado. He tachado mi error arriba.
- Entonces, para producir una lista de salida alfabética, ¿nos quedamos con notas al pie abreviadas , usando {{ sfn }} y {{ refbegin }}, como la única alternativa al estilo entre paréntesis desnudo? Eso produce buenos resultados donde hay muchas páginas citadas en unos pocos libros, pero ¿podría ser torpe de otra manera?
- Sería interesante tener una función en la que el lector pudiera ordenar el estilo de lista de referencias más común por autor, fecha u orden de ocurrencia según le convenga (similar a cómo se pueden ordenar las tablas).
- - Pelágicos ( mensajes ) - (07:38 miércoles 12, AEST) 21:38, 11 de agosto de 2020 (UTC)
- Pelagic escribió:
- Apoye cualquier tipo de estandarización que contribuya a una experiencia de lectura consistente en todos los artículos. ~ ToBeFree ( hablar ) 13:54, 9 de agosto de 2020 (UTC)
- Soporte , Actuary es un ejemplo perfecto de lo que está mal con este estilo. Los lectores esperan ver el número azul tradicional después de una declaración en un artículo de Wikipedia. Las citas entre paréntesis abarrotan el artículo y, debido a que no se usan comúnmente, los editores establecidos no necesariamente sabrán cómo agregar citas. La belleza del sistema de notas al pie es que todo lo que necesita hacer es insertar una etiqueta con una plantilla {{ cite }} y se formatea a sí mismo. La mayoría de los editores no están tan familiarizados con {{ harvnb }} y similares, y como resultado, me inclino a pensar que permitir citas entre paréntesis desalentará a otros editores de contribuir al artículo. Como ya han dicho otros, esta no es una razón para rechazar dichos artículos en AFC, pero es hora de que comencemos a estandarizar nuestro estilo de citas, y desaprobar los PIC es un buen lugar para comenzar. - desconcertado vegetal ¿ Ya es la hora del té? 13:58, 9 de agosto de 2020 (UTC)
- Responder No, es no un "ejemplo perfecto" de lo que está mal con este estilo. Como ya he señalado varias veces, los "problemas" se pueden solucionar mediante la edición normal, sin necesidad de deshacerse de las referencias entre paréntesis. - NSH001 ( conversación ) 08:51, 30 de agosto de 2020 (UTC)
- Comentario Debido a preocupaciones constantes, he agregado una sola palabra al texto de la propuesta original: "en línea", que es lo que pretendía y expliqué originalmente. Pido disculpas por cualquier confusión, ya que ni siquiera me di cuenta de que la gente llamaba entre paréntesis los estilos de referencia sfn / harv :) CaptainEek Edits Ho Cap'n! ⚓ 19:16, 9 de agosto de 2020 (UTC)
- @ CaptainEek : Pero eso es precisamente lo que está causando confusión: escribe
la gente llama estilos de referencia sfn / harv entre paréntesis
como si y hacen trabajos similares, no es así.{{sfn}}
{{harv}}
{{sfn}}
está esencialmente envuelto en - hace un poco [1] , y en la referencia que se muestra más adelante en la página no hay paréntesis (las letras "nb" significan "sin corchetes").{{harvnb}}
...
{{harv}}
está esencialmente entre paréntesis, pero no hay poco [1] o similar.{{harvnb}}
- Entonces, si bien es común para ambos, el resultado final es muy diferente. Es como el motor Coventry Climax FW: puede encontrarlo en máquinas tan diversas como bombas contra incendios, carretillas elevadoras y autos de carreras, pero nadie diría que son iguales entre sí. - Red rose64 🌹 ( charla ) 22:17, 9 de agosto de 2020 (UTC)
{{harvnb}}
- Como dije en mi primer comentario de enmienda: estoy de acuerdo con sfn. No estoy de acuerdo con harv solo. Las plantillas de Harv deben estar en etiquetas de referencia, de modo que formen un pequeño número azul. CaptainEek edita Ho Cap'n! ⚓ 22:20, 9 de agosto de 2020 (UTC)
- Nuevamente los estás mezclando. La plantilla no está diseñada para colocar etiquetas en el interior , se utiliza de forma independiente. Si desea poner algo relacionado con el interior , debe usar o . - Red rose64 🌹 ( charla ) 23:08, 9 de agosto de 2020 (UTC)
{{harv}}
...
{{harv}}
...
{{harvnb}}
{{harvcolnb}}
- Nuevamente los estás mezclando. La plantilla no está diseñada para colocar etiquetas en el interior , se utiliza de forma independiente. Si desea poner algo relacionado con el interior , debe usar o . - Red rose64 🌹 ( charla ) 23:08, 9 de agosto de 2020 (UTC)
- Como dije en mi primer comentario de enmienda: estoy de acuerdo con sfn. No estoy de acuerdo con harv solo. Las plantillas de Harv deben estar en etiquetas de referencia, de modo que formen un pequeño número azul. CaptainEek edita Ho Cap'n! ⚓ 22:20, 9 de agosto de 2020 (UTC)
- @ CaptainEek : Pero eso es precisamente lo que está causando confusión: escribe
- Soporte . Estuvo de acuerdo en que el estilo entre paréntesis genera desorden, y deberíamos intentar presentar los artículos de forma ordenada. Dicho esto, DGG (que se opone) hace un punto muy justo de que el marcado wiki para las citas en línea es novedoso para la mayoría de los usuarios nuevos, y no deberíamos rechazar artículos solo porque usan un estilo de cita incorrecto. Lo que creo que la desaprobación debería significar es que cualquier editor puede cambiar un artículo con estilo entre paréntesis a un estilo preferido, y se debe alentar a los editores novatos que lo usen, de una manera que no muerda , a usar los estilos preferidos. Sjakkalle (¡Compruebe!) 19:35, 9 de agosto de 2020 (UTC)
- Oponerse formalmente a la "desaprobación". Yo apoyo el principio general de decir que se prefieren las notas al pie, y animar a la gente a alejarse de las citas entre paréntesis simples, pero a mí "desaprobación" parece ser un paso más allá, e inevitablemente dará lugar a un conflicto sobre estilos de citas. Andrew Gray ( charla ) 20:05, 9 de agosto de 2020 (UTC)
- Oponerse . Para la mayoría de los oponentes anteriores, particularmente Wugapodes. Los beneficios para el lector parecen menores; de hecho, los lectores acostumbrados a los artículos científicos pueden preferir la forma entre paréntesis. Es probable que la molestia para los editores que prefieren las referencias entre paréntesis sea real. Si esta forma de citación está desapareciendo, déjela morir por sí sola; si no es así, es porque a algunos editores les gusta. En una nota de procedimiento, creo que cualquier cosa que pueda verse como un debilitamiento de CITEVAR debería publicitarse lo más ampliamente posible; ¿Dónde se han dejado los avisos hasta ahora? Mike Christie ( charla - contribuciones - biblioteca ) 20:39, 9 de agosto de 2020 (UTC)
- Mike Christie , Esto se encuentra actualmente en la plantilla de discusión centralizada, que es lo más visible posible. También dejé notas en algunas de las páginas del proyecto MOS para publicitarlo. Creo que otro usuario también lo difundió en algunos de los WikiProjects. CaptainEek edita Ho Cap'n! ⚓ 22:40, 9 de agosto de 2020 (UTC)
- CaptainEek : Creo que un aviso de lista de vigilancia estaría justificado; si no tiene objeciones puedo solicitarlo o usted puede. Lo mencionaré en WT: FAC , que es leído por muchos escritores de contenido que tal vez no vean otros foros. Mike Christie ( charla - contribuciones - biblioteca ) 00:11, 10 de agosto de 2020 (UTC)
- Mike Christie Creo que un aviso de lista de vigilancia probablemente sea excesivo, no puedo recordar la última vez que una política de RfC fue un aviso como ese. Pero no tengo objeciones a publicarlo en WT: FAC. CaptainEek edita Ho Cap'n! ⚓ 00:14, 10 de agosto de 2020 (UTC)
- Estoy de acuerdo con Mike C. Cuanto más visibilidad, mejor. Este es uno de esos asuntos por los que cualquiera se enojará por no haber dicho su artículo. Especialmente si él / ella está en el lado perdedor. - llywrch ( charla ) 21:38, 10 de agosto de 2020 (UTC)
- También podría repetir lo que he dicho en otra parte (veo a otros haciendo puntos similares muy arriba): "La" pregunta "de rfc está redactada de manera extremadamente confusa y ya se ha alterado dos veces al menos mientras se estaba ejecutando el rfc, incluido un problema que dista mucho de ser menor. Como resultado, los "apoyos" y los "oponentes" a menudo parecen estar hablando de puntos de vista diferentes y aspectos diferentes. No veo cómo se puede sacar una conclusión que cambie las políticas de lo que actualmente es un recuento de votos bastante equilibrado, para diferentes cosas. Tendría que haber otra etapa para discutir propuestas debidamente redactadas y votar sobre una serie de opciones. Podría ser demasiado pronto para levantar el fyrd en este momento. " Johnbod ( charla ) 21:50, 10 de agosto de 2020 (UTC)
- Mike Christie , Esto se encuentra actualmente en la plantilla de discusión centralizada, que es lo más visible posible. También dejé notas en algunas de las páginas del proyecto MOS para publicitarlo. Creo que otro usuario también lo difundió en algunos de los WikiProjects. CaptainEek edita Ho Cap'n! ⚓ 22:40, 9 de agosto de 2020 (UTC)
- La desaprobación del soporte , que espero será similar a hacer que CITEVAR ya no se aplique cuando se usa un estilo que usa citas entre paréntesis en línea (y entiendo que la esencia más arriba ha llegado a eso como el estado preferido). Creo que la mayoría de las anteriores han dejado claro por qué. Podría estar convencido de que el ocasional "Nombre y otros hicieron esto (fecha / año). " o "Nombre y otros (fecha / año) hicieron esto. " es razonablemente corto, pero no Creo que será necesario en el caso general.
En cuanto a las preocupaciones por morder, creo que la declaración en WP: la ventaja de CITE ya es suficiente (y si ve BITING, llame al usuario):
Si bien debe intentar escribir las citas correctamente, lo más importante es que proporcione suficiente información para identificar la fuente. Otros mejorarán el formato si es necesario.
En cuanto a las suposiciones sobre la comodidad, odié las referencias entre paréntesis desde el momento en que me pidieron que proporcionara citas en la escuela secundaria, y el estilo con el que crecí fue MLA. Lo cual fue predominantemente entre paréntesis. :) Pasemos de la forma de hacer las cosas en papel. - Izno ( charla ) 23:19, 9 de agosto de 2020 (UTC)
- Soporte . Estoy muy contento de que alguien haya hecho esta propuesta, y todavía no puedo creer que la gente en 2006 pensara que era una buena idea permitir este tipo de citación para un sitio web dirigido al público en general. La mejor forma de confundir al lector casual. T8612 (conversación) 00:49, 10 de agosto de 2020 (UTC)
- Apoye alentar el uso
y permitir la conversión de referencias entre paréntesis en prosa como "(Smith 2020)" o "Smith (2020)" para usarlas
de alguna manera sin la necesidad de un consenso adicional en cada artículo individual. Los artículos no deben eliminarse o rechazarse de AFC por usar un estilo entre paréntesis en lugar de
, como máximo, pueden etiquetarse para limpieza si no solo se convierten. De hecho, también me gustaría que {{ rp }} se desaprobara de la misma manera, incluso {{ sfn }} es mejor que ese lío. Anomie ⚔ 00:58, 10 de agosto de 2020 (UTC)
- Fuertemente apoyo . También apoyaría la IRL en desuso. GPinkerton ( charla ) 01:35, 10 de agosto de 2020 (UTC)
- Oponerse por CITEVAR - Guerillero | Parlez Moi 02:10, 10 de agosto de 2020 (UTC)
- Soporte : uso tales referencias en la vida real a diario, pero no son adecuadas para Wikipedia. Dado que tenemos tecnología disponible para minimizar la interrupción que tales citas causan en el texto, creo que deberíamos hacerlo. Me ha gustado mucho utilizar las plantillas de referencia de Harvard. Mientras que otros aquí parecen insinuar que esto desalentaría a los recién llegados, por el contrario, WikiGnomes vendrá y arreglará esas cosas por ellos, ¡idealmente enseñándoles cómo hacerlo ellos mismos! Así es como se realiza la mayor parte de este trabajo en Wikipedia, y no hay ninguna razón por la que no pueda suceder aquí. RGloucester - ☎ 13:44, 10 de agosto de 2020 (UTC)
- Oponerse : esto parece ser un intento de abolir CITEVAR y obligar a todos a usar el sistema de referencia "único verdadero", como se puede ver en los comentarios de User Anomie, donde admiten que su objetivo es prohibir todos los estilos de referencia de forma corta que no sean algunos. misterioso "sistema de referencia de libros que ni siquiera existe todavía - parece diseñado para ahuyentar a los editores en masa - y a pesar de lo que dicen los proponentes, esto sin duda se utilizará para morder a los creadores de contenido - al igual que el hecho de que las plantillas de cite xx son Los editores utilizan el apoyo de herramientas de edición para forzar el uso de estas plantillas, con frecuentes afirmaciones de que son "oficiales". Nigel Ish ( charla ) 16:29, 10 de agosto de 2020 (UTC)
- Estás asumiendo mucha mala fe aquí. T8612 (conversación) 19:26, 10 de agosto de 2020 (UTC)
- Apoye el alejamiento de las citas entre paréntesis (según Alsee). Creo que vale la pena considerar las preocupaciones de Wugapodes en el sentido de que a medida que las cosas se codifican más con el tiempo, la gente se preocupa más por hacer cumplir "las reglas" (considere cuánta sangre se ha derramado sobre las disputas de MOS), pero por otro lado algo como Trio sonata es un desorden enorme. bibliomaniac 1 5 19:13, 10 de agosto de 2020 (UTC)
- No es una comparación que valga la pena hacer. La gente se pelea por las cosas de MoS por la razón específica de que todos los usuarios fluidos e incluso los que quieren serlo tienen un sentido innato de dominio del idioma y de lo que es "correcto" e "incorrecto" en él (es decir, lo que eran enseñado), a pesar de que esos sentimientos absolutistas y prescriptivistas son objetiva y lingüísticamente absurdos en su mayor parte. El estilo de escritura es en su mayoría arbitrario y subjetivo, y la principal razón por la que nosotros (como todos los demás editores importantes) tenemos un estilo propio en todos los que escriben delicados es presentar una experiencia de lectura bastante uniforme y poner fin a varias tediosas "guerras de estilo". "que se vuelven recurrentes y circulares. Por el contrario, nadie tiene la ilusión psicológica de que un estilo de cita sea innatamente Correcto y otro un error. Cualquiera que sepa lo que es una cita sabe que vienen en diferentes formatos. Todos los que se encuentran en la escuela secundaria o la educación superior ya han aprendido que deben formatear las citas de manera diferente para diferentes clases, y todos los que publican artículos u otro material de manera profesional están completamente acostumbrados a tener que formatear las citas para que se adapten a revistas particulares u otras editoriales (o para haga que los editores hagan ese cambio por ellos). Por lo tanto, comparar las disputas de MoS con las disputas de CITEVAR es una falsa analogía. Solo son similares en que la gente se pone de mal humor y la palabra "estilo" está involucrada. - SMcCandlish ☏ ¢ 😼 02:23, 11 de agosto de 2020 (UTC)
- Eso es completamente razonable, y no tengo objeciones a eso. Pero también me resulta imposible subestimar la capacidad singular de los wikipedistas para debatir sobre cosas insignificantes ... bibliomaniac 1 5 02:43, 1 de septiembre de 2020 (UTC)
- No es una comparación que valga la pena hacer. La gente se pelea por las cosas de MoS por la razón específica de que todos los usuarios fluidos e incluso los que quieren serlo tienen un sentido innato de dominio del idioma y de lo que es "correcto" e "incorrecto" en él (es decir, lo que eran enseñado), a pesar de que esos sentimientos absolutistas y prescriptivistas son objetiva y lingüísticamente absurdos en su mayor parte. El estilo de escritura es en su mayoría arbitrario y subjetivo, y la principal razón por la que nosotros (como todos los demás editores importantes) tenemos un estilo propio en todos los que escriben delicados es presentar una experiencia de lectura bastante uniforme y poner fin a varias tediosas "guerras de estilo". "que se vuelven recurrentes y circulares. Por el contrario, nadie tiene la ilusión psicológica de que un estilo de cita sea innatamente Correcto y otro un error. Cualquiera que sepa lo que es una cita sabe que vienen en diferentes formatos. Todos los que se encuentran en la escuela secundaria o la educación superior ya han aprendido que deben formatear las citas de manera diferente para diferentes clases, y todos los que publican artículos u otro material de manera profesional están completamente acostumbrados a tener que formatear las citas para que se adapten a revistas particulares u otras editoriales (o para haga que los editores hagan ese cambio por ellos). Por lo tanto, comparar las disputas de MoS con las disputas de CITEVAR es una falsa analogía. Solo son similares en que la gente se pone de mal humor y la palabra "estilo" está involucrada. - SMcCandlish ☏ ¢ 😼 02:23, 11 de agosto de 2020 (UTC)
- Soporte He sugerido incluso versiones leves de esto antes y me han rechazado, pero es el mínimo básico para hacer cumplir los estándares útiles para nuestros lectores y editores. No encuentro las preocupaciones de que vaya a afectar materialmente las contribuciones, ya que esas personas no estaban leyendo nuestras guías de estilo para empezar. Charla de Der Wohltemperierte Fuchs 20:55, 10 de agosto de 2020 (UTC)
- Tampoco me gustan las citas entre paréntesis, pero el objetivo de CITEVAR es permitir que los editores que trabajan en un artículo usen lo que les gusta, no necesariamente lo que les gusta a los demás.
Primero vinieron para citas entre paréntesis, y apoyé el RfC, porque no uso citas entre paréntesis ...Mike Christie ( charla - contribuciones - biblioteca ) 21:23, 10 de agosto de 2020 (UTC)- Ley de Godwin . Por favor, por el amor de [cualquier cosa que jure], no vuelva a trivializar el Holocausto para participar en analogías de equivalencia falsa y falacias de pendiente resbaladiza sobre trivialidades de formato de citas. Eso es tan malo de muchas maneras. Si hubiera una pendiente resbaladiza real aquí, el resultado final sería solo un estilo de cita completamente consistente, que en realidad sería más fácil para todos, desde los lectores hasta los editores. ¿En qué túnel de realidad posible es comparable con el asesinato en masa de millones de personas organizado por el estado? FFS. Si no conociera la fuente de la frase, podría dejarla pasar, pero se vinculó directamente a ella y sabe exactamente lo que está haciendo. - SMcCandlish ☏ ¢ 😼 02:23, 11 de agosto de 2020 (UTC)
- Golpeado, ya que si te resulta ofensivo sin duda otros también lo harán. Solo quise retomar el tema de la escalada, no ninguna de las otras connotaciones. Y despojado de la metáfora ofensiva, sigo pensando que ese es el caso. Mike Christie ( charla - contribuciones - biblioteca ) 02:45, 11 de agosto de 2020 (UTC)
- Ley de Godwin . Por favor, por el amor de [cualquier cosa que jure], no vuelva a trivializar el Holocausto para participar en analogías de equivalencia falsa y falacias de pendiente resbaladiza sobre trivialidades de formato de citas. Eso es tan malo de muchas maneras. Si hubiera una pendiente resbaladiza real aquí, el resultado final sería solo un estilo de cita completamente consistente, que en realidad sería más fácil para todos, desde los lectores hasta los editores. ¿En qué túnel de realidad posible es comparable con el asesinato en masa de millones de personas organizado por el estado? FFS. Si no conociera la fuente de la frase, podría dejarla pasar, pero se vinculó directamente a ella y sabe exactamente lo que está haciendo. - SMcCandlish ☏ ¢ 😼 02:23, 11 de agosto de 2020 (UTC)
- Tampoco me gustan las citas entre paréntesis, pero el objetivo de CITEVAR es permitir que los editores que trabajan en un artículo usen lo que les gusta, no necesariamente lo que les gusta a los demás.
- Soporte : sí, el tiempo que usamos una forma de referencia que se adapta a una enciclopedia en línea. Las referencias entre paréntesis siempre han sido un arrastre de algunas tradiciones académicas en lugar de algo que se adapte a Wikipedia o sus lectores. Eso no quiere decir que las contribuciones con referencias entre paréntesis deban rechazarse, pero debemos establecer las etiquetas de referencia y las plantillas como el método preferido para proporcionar información de referencia. The Land ( charla ) 22:02, 10 de agosto de 2020 (UTC)
- Apoyo por la mayoría de las razones ya dadas. En resumen, deberíamos, como casi todos los demás editores del planeta, avanzar hacia un estilo de cita interno coherente. Incluso si preservamos varias formas de divergencia en un campo específico, no necesitamos tener todos los estilos de cita imaginables aquí, especialmente aquellos que solo tienen sentido en un contexto de papel , como los paréntesis en línea. Consulte también WP: NOT # JOURNAL . Imitar el viejo estilo de un diario de papel es simplemente un desorden molesto para nuestros lectores, que no son académicos y no necesitan cosas como "(Johnson 2005 págs. 345-352)" meter en la cara cada oración más o menos, cuando [7] bastará multa. - SMcCandlish ☏ ¢ 😼 02:23, 11 de agosto de 2020 (UTC)
- Fuerte apoyo . Uno de los mayores desvíos para los novatos. Es casi seguro que contribuye a nuestra alta tasa de salida e inhibe la creación de cuentas por parte de los anónimos. También es un aburrimiento para los editores establecidos. Tony (charla) 02:46, 11 de agosto de 2020 (UTC)
- @ Tony1 : ¿Cuál es su evidencia para su afirmación de que las citas entre paréntesis son
uno de los mayores desvíos para los novatos
, o quecasi con certeza contribuye a nuestra alta tasa de salidas
? Seguramente, es mucho más desalentador para ellos, o incluso una razón para renunciar, cuando sus adiciones de contenido se revierten con frecuencia por no tener fuentes (incluso considerando reversiones válidas de WP: BLP ). Ni una sola vez me he encontrado con un novato, o incluso un veterano, que haya comentado algo como "Acabo de encontrar un artículo que usa citas entre paréntesis y no puedo averiguar cómo hacerlo, por lo tanto, me he quedado sin aquí." Hay muchos que han renunciado porque no les permitimos crear una página sobre la banda que acaban de formar en el garaje del padre de Bob . - Estoy aún más perdido al ver cómo las citas entre paréntesis
inhibe la creación de cuentas por parte de los anónimos
: no veo la conexión por completo. - Red rose64 🌹 ( charla ) 11:27, 11 de agosto de 2020 (UTC) - No, es poco probable que desactive a los novatos, cuando no es tan común. Puedo sugerir fácilmente un candidato mucho más probable. Suponga que es un novato y abre una página en edición en modo de edición, y ve este montón de basura incomprensible e ilegible (tomada de una página que estaba mirando justo antes de ver su publicación por primera vez):
Durante la guerra, Israel también dañó hospitales, {{cite web | last1 = Cohen | first1 = Gili; Hass, Amira; Khoury, Jack | title = Israel bombardea el hospital de Gaza vacío, llamándolo centro de comando de Hamas | url = http: //www.haaretz.com/news/diplomacy-defense/.premium-1.606912 | sitio web = haaretz.com | editor = Haaretz Daily Newspaper Ltd. | fecha de acceso = 12 de agosto de 2014}} alegando que ocultaban "misiles ocultos". [http://www.washingtonpost.com/blogs/worldviews/ wp / 2014/07/22 / en-la-lucha-entre-israel-y-hamas-gazas-hospitales-están-en-el-medio] "Los hospitales de Gaza en el medio entre Israel y Hamas", '' washingtonpost. com ''; consultado el 23 de julio de 2014. Un equipo de reporteros finlandeses de [[Helsingin Sanomat]] la vida en el [[hospital Al-Shifa]] de Gaza informó haber visto cohetes disparados desde cerca del hospital Al-Shifa. {{cite web | title = Reportero de Helsingin Sanomat confirma las antiguas afirmaciones israelíes de que los misiles de Hamas se lanzaron desde el complejo de Shifa | url = http: //www.timesofisrael.com/finnish-tv-rockets-fired-from-gaza-hospital/}} < / ref> [http://www.ynetnews.com/articles/0,7340,L-4553643,00.html] "VIDEO: Reportero finlandés ve cohetes disparados desde un hospital de Gaza", [[ynet]], 2 de agosto de 2014. Sin embargo, dos médicos noruegos que han estado trabajando en el hospital durante décadas han negado que hubiera presencia militante cerca, diciendo que el último hombre armado que vieron junto al edificio era un médico israelí en el momento del [ [Primera Intifada]]. {{cite news | url = http: //www.haaretz.com/weekend/twilight-zone/.premium-1.608239 | title = 'Israel ha robado el futuro de Gaza y su esperanza' | fecha = 2 de agosto de 2014 | publisher = Haaretz}} The Was hington Post describió el hospital Al-Shifa como una "sede de facto para los líderes de Hamas, que se pueden ver en los pasillos y oficinas". https://www.washingtonpost.com/world/middle_east/ while-israel-held -su-despidió-al-grupo-militante-hamas-no / 2014/07/15 / 116fd3d7-3c0f-4413-94a9-2ab16af1445d_story.html Nick Casey del [[Wall Street Journal]] tuiteó una foto de un funcionario de Hamas que usa el hospital Al-Shifa para entrevistas con los medios, pero luego borró el tweet. http://www.jpost.com/Operation-Protective-Edge/Gaza-reporters-tweets-Hamas-using- human-shields-368689 # El periodista franco-palestino Radjaa Abu Dagg informó que fue interrogado por un miembro armado de Hamas dentro del hospital Al-Shifa y se le ordenó salir de Gaza. http://www.tabletmag.com/scroll /180730/top-secret-hamas-command-bunker-in-gaza-revealedhttp://actualite-israel.com/les-menaces-du-hamas-sur-un-journaliste-tu -dois-quitter-gaza-au-p-410595 / http://www.algemeiner.com/2014/07/24/french-journalist-de interrogatorio-de-escribas-en-la-sede-de-hamas-junto-a-la-sala-de-emergencias-en-el-hospital-gazas-al-shifa /
- @ Tony1 : ¿Cuál es su evidencia para su afirmación de que las citas entre paréntesis son
- @ NSH001 : Su argumento se desmorona cuando considera que es más probable que los nuevos usuarios usen el editor visual de todos modos. Noahfgodard ( charla ) 21:40, 29 de agosto de 2020 (UTC)
- @ NSH001 : Por eso me gustan las referencias definidas por lista. Pero tienen la desventaja de que necesita dos ediciones de sección separadas para agregar texto y referencia. Pelágicos ( mensajes ) - (17:27 jueves 20, AEST) 07:27, 20 de agosto de 2020 (UTC)
- De hecho es así. Hay cuatro formas diferentes de deshacerse de los montones de estiércol , y las referencias definidas por listas es una de ellas. Cada método tiene ventajas y desventajas. He escrito una herramienta (el script ETVP) que ofrece la opción de las cuatro. Puede ver ejemplos de su uso en Usuario: NSH001 / ETVP / examples . Pero tenga en cuenta que el script de ETVP es privado, por lo que solo yo puedo usarlo, aunque eventualmente podría estar disponible públicamente. - NSH001 ( conversación ) 09:39, 20 de agosto de 2020 (UTC)
- @ NSH001 : Por eso me gustan las referencias definidas por lista. Pero tienen la desventaja de que necesita dos ediciones de sección separadas para agregar texto y referencia. Pelágicos ( mensajes ) - (17:27 jueves 20, AEST) 07:27, 20 de agosto de 2020 (UTC)
- Oponerse En primer lugar, una razón pragmática: agregar citas de British History Online es engorroso sin citas con formato simple, porque no se proporcionan en una plantilla compatible con Wikipedia, por lo que no se pueden cortar y pegar. Por lo tanto, a menos que un gnomo esté preparado para seguir a las personas y arreglarlos, no creo que sea práctico. La segunda razón es que creo que esto tiene la oportunidad de hacer que Wikipedia: Arbitraje / Solicitudes / Caso / Civilidad en las discusiones del cuadro de información parezca una fiesta del té de la vicaría (al menos si los hilos como estos son algo por lo que pasar). Por favor , centrémonos en mejorar la enciclopedia para los lectores y en no generar grandes conflictos por cosas triviales. Ritchie333 (charla) (continuación) 09:32, 11 de agosto de 2020 (UTC)
- ¡No! ¿Y cómo te atreves a usar un guión en lugar de un guión? ¡Es indignante que un administrador desobedezca abiertamente nuestras políticas y pautas! [FBDB] Le v ! v ich 17:28, 11 de agosto de 2020 (UTC)
- Oponerse Mi mente se sorprendió al darme cuenta de que Wikipedia ni siquiera tiene un solo formato de cita estándar. Hasta el momento en que lo haga, parecería cruel e inusual comenzar a firmar formularios individuales como si fueran de alguna manera inferiores, pero el resto son frijoles geniales, solo use lo que quiera, mezcle incluso. Y además, ¿Wikipedia ready necesita decirle a la gente que está acostumbrada a usar este formato en particular como parte de su escritura diaria, que se larguen de aquí con su estupidez? Jenga Fet ( charla ) 19:41, 11 de agosto de 2020 (UTC)
- Hay razones válidas por las que el uso de citas en plantilla nos ayuda a evitar WP: LINKROT y a mantener la coherencia dentro de un artículo. La referencia entre paréntesis es uno de los pocos estilos comúnmente utilizados que no usa plantillas y, por lo tanto, es un objetivo obvio para destacar. Sin embargo, hace un buen punto que es importante conservar la buena voluntad de los editores. - RexxS ( charla ) 20:08, 11 de agosto de 2020 (UTC)
- RexxS , ¿ entonces qué ? - Red rose64 🌹 ( charla ) 20:40, 11 de agosto de 2020 (UTC)
{{harv}}
- @ Redrose64 : Es una plantilla obsoleta. - RexxS ( conversación ) 20:52, 11 de agosto de 2020 (UTC)
- Obsoleto ¿por qué? Su página de documentos no sugiere eso, y no puedo encontrar ninguna discusión de eliminación aparte de esta de hace ocho años, que se cerró como nieve. - Red rose64 🌹 ( charla ) 21:54, 11 de agosto de 2020 (UTC)
- Obsoleto porque nadie lo usa. Se puede encontrar en menos del 0,1% de nuestros artículos, y la mayoría de ellos son usos indebidos. Consulte la nota al pie de página n. ° 22 de Darth Vader para ver un ejemplo clásico de por qué no lo necesitamos. - RexxS ( charla ) 22:05, 11 de agosto de 2020 (UTC)
- Obsoleto ¿por qué? Su página de documentos no sugiere eso, y no puedo encontrar ninguna discusión de eliminación aparte de esta de hace ocho años, que se cerró como nieve. - Red rose64 🌹 ( charla ) 21:54, 11 de agosto de 2020 (UTC)
- @ Redrose64 : Es una plantilla obsoleta. - RexxS ( conversación ) 20:52, 11 de agosto de 2020 (UTC)
- RexxS , ¿ entonces qué ? - Red rose64 🌹 ( charla ) 20:40, 11 de agosto de 2020 (UTC)
- Nadie aquí dijo que los editores que usaban el estilo de paréntesis fueran estúpidos. Corta eso. T8612 (conversación) 20:56, 11 de agosto de 2020 (UTC)
- Hay razones válidas por las que el uso de citas en plantilla nos ayuda a evitar WP: LINKROT y a mantener la coherencia dentro de un artículo. La referencia entre paréntesis es uno de los pocos estilos comúnmente utilizados que no usa plantillas y, por lo tanto, es un objetivo obvio para destacar. Sin embargo, hace un buen punto que es importante conservar la buena voluntad de los editores. - RexxS ( charla ) 20:08, 11 de agosto de 2020 (UTC)
- Oponerse . Supongo que es lo que estoy acostumbrado por mi formación académica, pero me gusta leer en el texto quién ha escrito la referencia y cuándo, en lugar de tener que mover el cursor para averiguarlo. En segundo lugar, a menudo es necesario decir lo que se escribió en un artículo en particular. Parece mucho más ordenado escribir "Smith (1999) argumentó esto", que " 5 argumentó esto". Habiendo dicho eso, la mayoría de las veces escribo usando el estilo de referencia común de Wikipedia: pero quiero mantener la opción de no hacerlo. Jmchutchinson ( charla ) 19:46, 11 de agosto de 2020 (UTC)
- "Smith argumentó este 5 ". CMD ( charla ) 04:11, 12 de agosto de 2020 (UTC)
- Apoye la fuerte desaprobación de este estilo que rara vez se usa y que está en desacuerdo con la forma en que trabajan la mayoría de los editores. En mis artículos académicos utilizo el estilo autor / año entre corchetes cuando puedo, pero para una enciclopedia es realmente una interrupción para el lector y, en este caso, también para nosotros, los escritores que tenemos que trabajar en tales artículos. Dicklyon ( charla ) 00:37, 12 de agosto de 2020 (UTC)
- APOYO Sugeriría que esta propuesta es lo opuesto a CREEP ya que simplificar cosas como las referencias no es algo malo. Recuerde que el principio KISS es más útil que un obstáculo para los novatos. Saludos, GenQuest "Talk to Me" 03:01, 12 de agosto de 2020 (UTC)
- Argumentos muy extraños. Las referencias entre paréntesis son extremadamente fáciles de hacer, sobre todo para aquellas que no se utilizan para marcar o utilizar plantillas. Es el lector quien las padece. En la práctica, estos días son utilizados casi exclusivamente por novatos, quienes pueden dejar sus cosas sin referencia si se les dice que no las usen. Johnbod ( charla ) 04:08, 12 de agosto de 2020 (UTC)
- Oponerse En primer lugar, esta propuesta no está bien pensada. No aclara qué estilos está prohibiendo. En segundo lugar, no estoy de acuerdo en que todos los estilos entre paréntesis se interpongan en el camino para un lector, y de los que lo hacen, el sistema sfn, donde un pequeño número azul enlaza con un paréntesis, que a su vez enlaza con una entrada de bibliografía está en mi ver más confuso y más difícil de leer (no solo escritor) que el formulario donde un paréntesis en línea enlaza directamente a una entrada de bibliografía. Hay ventajas en una bibliografía ordenada por autor, o en algunos casos por una fecha, particularmente cuando las fuentes cubren un amplio rango de tiempo. Existe una ventaja para que el lector sepa sin seguir nada, solo quién dijo qué y cuándo en algunos temas, como se señaló anteriormente. Pero, sobre todo, creo que este debilitamiento o abolición de WP: CITEVAR daría lugar a una gran ronda de guerras de edición. Si vamos a comenzar a desaprobar los formatos de citas inusuales, ¿qué tal el estilo de Bluebook mucho más difícil para los lectores no especializados, en el que algunos editores insisten en temas legales? ¿Qué tal exigir el uso de plantillas de citas, o al menos el uso de
...
etiquetas? De hecho, me encantaría exigir referencias definidas por lista, pero no muchos estarían de acuerdo. Puedo ver una declaración general de que se favorecen los estilos que usan etiquetas ref. Me gustaría agregar una declaración que favorezca el uso de plantillas de citas. Pero tenemos suficientes problemas para conseguir que los nuevos editores vayan más allá de las URL simples. Creo que esto tendrá poca ganancia, y el potencial de problemas importantes y una pérdida de tiempo importante. DES (charla) DESiegel Contribs 15:59, 12 de agosto de 2020 (UTC) - Por lo que puedo ver, no soporto ningún inconveniente que prefiera las notas a pie de página. Las citas en línea (Smith 2008) son, en el 99% de los casos, una distracción excesiva y funcionan activamente para evitar la verificabilidad (números de página); también según el punto de BD2412. ( t · c ) buidhe 21:42, 12 de agosto de 2020 (UTC)
- Si una cita determinada tendrá números de página o no, es independiente del estilo de la cita. Cada estilo le permite tener números de página y es elección del editor si los proporciona o no en cada instancia. - Uanfala (conversación) 19:21, 17 de agosto de 2020 (UTC)
- Apoyo ... hasta cierto punto . Traté de leer todos los comentarios anteriores y me alegro de haberlo hecho, porque se hicieron algunos puntos opuestos muy buenos (por ejemplo, por Wugapodes) que no habría considerado en absoluto. Pero después de que un par de editores mencionaron el artículo de Actuary , solo tuve que seguir el enlace allí, y realmente se ve terrible . Las citas entre paréntesis en línea no le hacen ningún favor a nadie; es una presentación visual muy pobre y, sin embargo, se evita fácilmente. Me gustaría verlos fuertemente desanimados aquí, al menos. En cuanto a la consideración de nuevos usuarios, lo cual es importante, creo que se les debería recomendar que coloquen todas las referencias (independientemente de cómo hayan elegido redactar el contenido) dentro de las etiquetas de referencia. Estoy de acuerdo con el sentimiento expresado anteriormente de que agregar estas etiquetas no debería representar un gran desafío para nadie. En la academia y en las obras de referencia en general, las citas entre paréntesis en línea todavía se usan ampliamente, sí, pero al escribir artículos aquí sobre la música popular y la sociedad de la década de 1960, descubrí que los títulos de las editoriales universitarias de Oxford, Cambridge, Harvard, Chicago y similares. volver a las citas de notas al pie o notas al final de los libros dirigidos a un público más general. Me parece que deberíamos seguir ese enfoque, debido a la gran cantidad de lectores que atrae Wikipedia y para garantizar que la información se presente en la página sin distracciones innecesarias.
- No apoyo la defensa del uso de sólo un "sistema de notas a pie de página compatible con software" en su lugar (si he entendido el término correctamente, no me parece que WhatamIdoing haya obtenido una respuesta clara cuando solicité alguna aclaración). Tampoco la idea de que deberíamos buscar avanzar hacia un método de cita única, como también se ha sugerido. Si "soportado por software" significa citar 1/2 plantillas, entonces no, definitivamente no. Creo que cuanto menos control se coloque en unos pocos editores de plantillas de citas, con respecto a las opciones permitidas dentro de ciertos parámetros y, por lo tanto, cómo se representan los detalles en la página, mejor. JG66 ( charla ) 12:05, 13 de agosto de 2020 (UTC)
- Soporte No me encuentro con este estilo muy a menudo aquí y, al ver algunos de los artículos mencionados anteriormente, puedo ver por qué. Son una monstruosidad que da como resultado un mar de azul e inhiben el flujo del artículo. Algunas oraciones son más referencias que palabras reales. Tenemos un estilo estándar en la medida en que la gran mayoría de nuestros artículos usan los números de referencia pequeños y somos lo suficientemente grandes y hemos existido lo suficiente como para que este sea el estilo esperado para la mayoría de los usuarios y lectores. Debe alentarse hasta el punto en que cambiar las referencias en línea a números no sea controvertido, pero las referencias no deben eliminarse por completo, convertirse a un estilo completamente diferente o usarse como un garrote para los novatos que podrían usarlo porque ese es el único estilo. ellos saben. Al igual que nosotros hacemos wikify con buen sentido, pero artículos mal formados en este momento. AIR corn (charla) 23:02, 13 de agosto de 2020 (UTC)
- Oponerse . No me gusta este estilo, pero esa no es razón para decirle a la gente que deje de usarlo. Y, finalmente, alguien va a utilizar este RFC como justificación para venir después de un estilo de citas que hago similares. NinjaRobotPirate ( charla ) 15:31, 14 de agosto de 2020 (UTC)
- Fuerte oposición por DGG , David Eppstein y otros. Necesitamos hacer que agregar referencias sea lo más fácil posible. Las cuestiones de coherencia y estilo son, en el mejor de los casos, terciarias. Paul August ☎ 15:55, 15 de agosto de 2020 (UTC)
- Apoyo en el sentido de que otorga a otros la prerrogativa de convertir el paréntesis en una nota al pie. Obviamente, entre paréntesis es mejor que nada en absoluto. Pero las notas a pie de página son mejores para los lectores y se han convertido orgánicamente en el estilo de nuestra casa. Nada de esto hace que las referencias sean más difíciles de agregar, como han dicho otros. Si algunos prefieren hacer paréntesis, los gnomos pasarán y los cambiarán. Calliopejen1 ( charla ) 00:14, 16 de agosto de 2020 (UTC)
- Comentar . He publicado una solicitud de un aviso de lista de seguimiento para este RfC aquí ; por favor comente allí si tiene una opinión. Mike Christie ( charla - contribuciones - biblioteca ) 19:19, 16 de agosto de 2020 (UTC)
- Oponerse firmemente a la desaprobación de cualquier estilo de cita. Por mucho que detesto ciertos estilos, WP: CITEVAR es tanto un baluarte contra las guerras de edición divisivas y, en última instancia, inútiles como WP: ENGVAR y WP: ERA . Nuestras políticas principales incluyen WP: V , pero no incluyen WP: MOS ; La coherencia de la apariencia dentro de un artículo es deseable, entre los artículos es un asunto menor o incluso contraproducente, ya que las preferencias de algunos lectores y las convenciones de los campos inevitablemente no estarán representadas después de que las páginas no conformes se cambien para que se ajusten. Animar a las personas a que proporcionen citas y animarlas a que vayan más allá de los enlaces simples y los enlaces en línea en el texto al hacerlo, es una alta prioridad y esto desanimaría a algunas, las referencias en línea no hacen daño, y preferiría tener los gnomos realizan tareas útiles; Ya hay demasiados retoques con los formatos de citas que utilizan AWB. Yngvadottir ( charla ) 23:43, 16 de agosto de 2020 (UTC)
- Oponerse a la total desaprobación sin prejuicios contra la preferencia por otros estilos en la gran mayoría de los casos por los anteriores. - Godsy ( TALK CONT ) 13:12, 17 de agosto de 2020 (UTC)
- Soporte Ya no necesitamos tolerar otros estilos. El tipo de editores que algunos de ustedes creen que vendrán a Wikipedia con referencias entre paréntesis no existen o pueden aprender de otra manera. Chris Troutman ( charla ) 13:46, 17 de agosto de 2020 (UTC)
- Fuerte apoyo Es a la vez confuso e hipócrita hacer cumplir WP: MOS para obtener uniformidad de apariencia en todos los demás aspectos o apariencia, excepto en las referencias. La presentación de la información de buena calidad y estandarizada es esencial, y las referencias son uno de los elementos más importantes de nuestras páginas. Sin embargo, nuestra orientación sobre cómo hacerlo ha sido lamentablemente inadecuada durante años, y hemos permitido múltiples enfoques de referencia, que dudo que ningún editor o revista aprobaría. Y digo esto como autor de libros y artículos que ha utilizado referencias entre paréntesis en la impresión.
- Simplemente lea el encabezado de Actuario para apreciar lo ridículo que es tener este estilo incómodo y notoriamente diferente para hacer referencia a la presentación dentro de un artículo de Wikipedia, y luego considere que los candidatos al artículo destacado tienen que preocuparse por si los guiones cortos o cortos se usan correctamente. e innumerables otras minucias. Nuestro enfoque no estándar para fomentar una forma de referencia parece similar al Traje nuevo del Emperador . Todos podemos ver que hay un problema, pero llevamos tanto tiempo creyendo que tener múltiples estándares está bien que se ha arraigado y nos negamos a ver que hay un problema. En lugar de preocuparnos por desanimar a los colaboradores académicos que son, por definición, individuos relativamente inteligentes que son capaces de adaptarse, deberíamos preocuparnos por asegurarnos de que se aliente a todos los demás editores nuevos a usar un estilo para las citas en línea y a estar dispuestos a ver artículos convertidos activamente en ese estilo de casa preferido para hacer referencia, tal como lo hacemos para todo lo demás aquí.
- El argumento para mantener citas entre paréntesis en línea en Wikipedia porque los científicos sociales y otros lo prefieren es similar a mí, como naturalista, exigiendo que permitamos letras mayúsculas para los nombres comunes de plantas y animales en todos los artículos directamente sobre una especie porque así es como prefieren los naturalistas. verlos escritos, porque evita confusiones. Wikipedia estuvo de acuerdo en un enfoque al respecto, y debemos ceñirnos a él; ahora deberíamos aceptar lo obvio y deslumbrante y comenzar a limpiar los múltiples enfoques que hemos tolerado y alentado durante demasiado tiempo para hacer referencia. Nick Moyes ( charla ) 23:36, 17 de agosto de 2020 (UTC)
- Soporte . Los beneficios obvios superan con creces los costos (en su mayoría teóricos). Yilloslime ( charla ) 03:27, 18 de agosto de 2020 (UTC)
- Oposición muy fuerte . En mi opinión, esta propuesta no es un principio y nunca debería permitirse que se apruebe. El proponente menciona el artículo Actuario . Como yo mismo soy actuario (pero retirado hace mucho tiempo), este artículo ha estado en mi lista de seguimiento desde casi el día en que me uní a Wikipedia en 2006. El artículo fue escrito por el excelente Usuario: Avraham ("Avi" para abreviar) - otro actuario - uno de los mejores administradores y burócratas de Wikipedia, ampliamente respetado por su arduo trabajo constante, integridad, buen juicio y escrupulosa adherencia a las políticas de Wikipedia. Lamentablemente, no es muy activo en Wikipedia en este momento, pero sería bueno verlo de regreso y contribuir a esta discusión. De todos modos, el estilo de las citas en Actuary nunca me ha molestado. No es mi estilo preferido, pero no tiene nada de malo. Si el "desorden" molesta tanto a la gente, hay algunos cambios simples que mencioné en Talk: Actuary para lidiar con eso, como reducir la cantidad de citas en el cliente potencial (por política, un cliente potencial sin ninguna cita está perfectamente bien si el material se encuentra en otra parte del artículo) y, en la medida de lo posible, manteniendo las citas hasta el final de las oraciones. No, el "problema" (si es un problema, que no creo que lo sea) no es el estilo de las citas, sino la disposición particular de las citas en ese artículo, que se soluciona fácilmente. También vale la pena señalar que este es un artículo destacado, y si el estilo de las citas realmente fuera un problema, los revisores de FA ya lo habrían resuelto. Cito de lo que escribí en la charla: Actuario ,
Da la casualidad de que recientemente he estado editando más artículos sobre matemáticas. Hay buenas razones para no utilizar citas con superíndice en los artículos de matemáticas. Uno de ellos es obvio: los superíndices, cuando se colocan junto a una expresión matemática, pueden malinterpretarse fácilmente como parte de la expresión. (Lo mismo se aplica a las fórmulas químicas). Pero la objeción va mucho más allá. Tome un artículo en el que estuve trabajando recientemente: grupo de monstruos , que está escrito usando referencias entre paréntesis. Luego, piense cómo lo cambiaría para usar referencias en superíndice. En primer lugar, el trabajo no sería fácil y, en segundo lugar, el resultado sería peor , no mejor. Lo último que necesitamos es un cambio de política que empeoraría (algunos) artículos. Y digo "No, gracias" a la guerra de edición interminable, contraproducente y que desperdiciaría el tiempo que resultaría. No, deberíamos permitir que los editores utilicen, a su discreción, el mejor estilo de cita para un artículo en particular. Y si alguien piensa que se debe cambiar el estilo de las citas en un artículo individual, ya tenemos políticas que funcionan bien: WP: CITEVAR y WP: CITESTYLE . Ahora tratemos algunos de los puntos planteados por el proponente y otros aquí.En primer lugar, sigo sin convencerme del argumento de las "quejas". Más bien, me parecen personas que dicen: "No he visto esto antes, por lo tanto, no me gusta". Como todo lo nuevo, es posible acostumbrarse a él y, eventualmente, apreciar sus ventajas.
- El proponente comienza refiriéndose a un caso de Arbcom de 2006 que sustenta el actual WP: CITEVAR , opinando que las cosas han cambiado desde entonces y argumentando que deberíamos desaprobar las referencias entre paréntesis en línea. Ahora, algunas cosas han cambiado desde entonces. El mayor problema, según lo recuerdo de 2006, era si las citas manuales debían convertirse o no para usar plantillas de citas. Algunos editores muy conocidos y de alto perfil se opusieron firmemente al uso de plantillas de citas. El resultado fue una política que Wikipedia no fomenta ni desalienta el uso de plantillas de citas (estoy parafraseando aquí). Hasta donde yo sé, esta política sigue en pie, de jure . Pero en la práctica, todos los días veo editores ocupados convirtiendo citas manuales en plantillas. (Por cierto, hacen un muy mal trabajo con esto, porque las herramientas generadoras de citas que utilizan son muy malas). En su mayoría, esta política se ignora de facto . En 2006, existía una fuerte justificación para evitar las plantillas de citas. Debido a limitaciones técnicas, la gama de opciones que ofrecían era inadecuada y eran computacionalmente muy ineficientes (en inglés simple: muy lento). Un artículo que cita unas 400 fuentes que utilizan plantillas tardó unos 5 minutos en cargarse (estoy pensando en la Guerra de Gaza (2008-2009) ). A los editores que prefirieron las citas manuales les gustó el control detallado que podían tener, que no les ofrecían las plantillas disponibles en ese momento. Hoy en día, gracias al arduo trabajo de algunos técnicos brillantes, estas objeciones se han cumplido en su mayoría, y las nuevas plantillas se ejecutan varios órdenes de magnitud más rápido que las antiguas. Así que personalmente estoy a favor del uso de plantillas, pero, no obstante, sigo pensando, en principio, que los editores deberían poder utilizar citas manuales si así lo desean. El punto al que estoy llegando (laboriosamente) es este: Sí, las cosas siguen adelante, lo que hace una diferencia en la cuestión de las plantillas de citas. Pero no hay ningún cambio comparable, o "seguir adelante", que haga alguna diferencia en la cuestión de las referencias entre paréntesis.
- La principal objeción - que "abarrota" el texto - es una cuestión de gusto personal, no de principios. Una vez que te acostumbras, empiezas a apreciar sus ventajas. En artículos como Monster Group , las ventajas sobre las referencias en superíndice son obvias. Las referencias entre paréntesis se leerán de forma natural y sencilla allí, mucho mejor que las citas en superíndice. Al igual que las referencias abreviadas y las referencias definidas por lista, las referencias entre paréntesis tienen la ventaja de eliminar el desorden de enormes plantillas de citas del cuerpo del artículo. Comparte, con referencias abreviadas, la ventaja de proporcionar una lista bibliográfica agradable, ordenada y ordenada alfabéticamente al final del artículo. Además de eso, tiene la ventaja sobre la forma corta de prescindir por completo de una sección de "citas" y de requerir un clic menos para llegar allí. Los lectores también pueden ver, allí mismo en el texto, quién ha escrito la fuente y cuándo, completar con los números de página, si corresponde. No es necesario maniobrar con cuidado el mouse para colocar el cursor sobre el superíndice o hacer clic en él para ver qué hay debajo.Volviendo a Actuary nuevamente, las objeciones menores que existan se pueden resolver mediante la edición normal del líder. Simplemente lea todo el artículo nuevamente, por favor. Aparte del plomo, se lee perfectamente bien y fácilmente. No es necesario deshacerse de las referencias entre paréntesis.
- No me he molestado en repetir los puntos de Wugapodes, pero insto a los lectores a que vuelvan y los lean. Del mismo modo por las excelentes contribuciones realizadas por los usuarios DGG, David Eppstein y Finnusertop.
- Este es un mal cambio en principio, por la misma razón que estoy a favor de permitir que los editores usen citas formateadas manualmente si lo desean, aunque personalmente estoy firmemente a favor de usar plantillas de citas. Esta es una propuesta muy, muy mala. Solo piense en la obvia estupidez de prohibir un estilo de cita perfectamente fino, que de hecho es lo mejor para algunos artículos, solo porque alguien podría haber puesto demasiadas citas a la cabeza de un artículo en particular. Esta propuesta debe ser enterrada firmemente en el lugar que le corresponde, a dos metros bajo tierra, y de manera permanente, sin esperanza de resurrección, por favor. - NSH001 ( conversación ) 07:43, 18 de agosto de 2020 (UTC)
- Propuesta de soporte . Si bien entiendo los deseos de los editores de usar el estilo con el que se sienten más cómodos, en una visión más amplia, eso es contraproducente para la wiki. Los lectores que vayan de un artículo a otro y deseen comprobar las fuentes deben adaptarse a un nuevo estilo. El estilo en línea es mucho menos amigable para el lector que el estilo de referencia que permite al lector ver la fuente sin saturar el texto y sin forzarlos a desplazarse hacia abajo en la página, dejando el lugar en el que estaban. - Gonnym ( charla ) 08:36, 18 de agosto de 2020 (UTC)
- Err, las referencias entre paréntesis no "obligan" a nadie a desplazarse hacia abajo en la página ni a abandonar el lugar en el que estaban. Todo lo contrario. - NSH001 ( conversación ) 09:04, 18 de agosto de 2020 (UTC) P
- Por favor, use mis palabras en el contexto en el que fueron escritas:
permite al lector ver la fuente sin [...] obligarlos a desplazarse hacia abajo en la página
; no puede ver una fuente completa de "(Thomas 2012) sin desplazarse hacia abajo en la página. - Gonnym ( charla ) 09:38, 18 Agosto 2020 (UTC)- Sí, puede, siempre que la página utilice una de las plantillas de la familia {{ harv }}. Supongo que este es otro ejemplo de la naturaleza pobremente expresada de la propuesta, que menciona citas entre paréntesis de texto en línea, pero luego objeta sobre Actuary , cuyas citas entre paréntesis se basan completamente en plantillas. - NSH001 ( hablar )
- Por favor, use mis palabras en el contexto en el que fueron escritas:
- Err, las referencias entre paréntesis no "obligan" a nadie a desplazarse hacia abajo en la página ni a abandonar el lugar en el que estaban. Todo lo contrario. - NSH001 ( conversación ) 09:04, 18 de agosto de 2020 (UTC) P
- Apoyo por propuesta: las citas entre paréntesis abarrotan el texto y dificultan la lectura. Después de leer todos los contraargumentos anteriores y comprobar todas las páginas de ejemplo, nada me convence de que los beneficios de mantener el estilo superen las desventajas. MichaelMaggs ( charla ) 09:57, 18 de agosto de 2020 (UTC)
- Oponerse . En primer lugar, no veo la necesidad de una nueva regla, ya que las citas entre paréntesis en línea ya son bastante raras y en los artículos dirigidos a los lectores más generales son casi inexistentes. Por otro lado, en algunos artículos especializados (piense, por ejemplo, en temas oscuros en álgebra abstracta), es probable que sean tan familiares para los lectores como para los escritores de esos artículos. E incluso cuando se utilizan citas con formato , a veces se da un caso en el que el hecho de quién escribió el texto citado, o cuándo lo escribió, es de relevancia enciclopédica. Entonces, una cita entre paréntesis es la forma más económica de transmitir ese hecho; la alternativa de usar una nota a pie de página y luego expandir la prosa con la información relevante en realidad agregaría más desorden. Y como señala NSH001, en algunos temas (como las matemáticas), las referencias en forma de números en superíndice tienen el potencial de interferir con el contenido. Además, como han explicado Wugapodes, DGG, Finnusertop y otros, la prohibición de este estilo de cita disuadirá a los posibles nuevos editores que no queremos disuadir, y la aplicación de la prohibición alejará a los editores existentes que no queremos que se alejen. Sí, en algunos casos (incluidos los artículos dirigidos a una audiencia general, como Actuario ), la conversión de citas entre paréntesis en línea conducirá a una mejor presentación. En lugar de adoptar una prohibición general, los editores pueden considerar intentar conversiones reflexivas (como en el artículo del actuario, pero como señala NSH001, incluso entonces puede que no sea necesariamente la mejor solución). También me parece que las ventajas para la legibilidad se han exagerado en esta discusión. Las referencias entre paréntesis hacen que sea mucho más fácil para un lector ir y venir entre el texto y las fuentes (especialmente en comparación con el sistema {{ sfn }} donde siempre tienen que hacer clic en las notas al pie de página). - Uanfala (charla) 14:43, 18 de agosto de 2020 (UTC)
- Se supone que nuestros artículos deben ser "comprensibles para la mayor cantidad posible" y "escritos en un idioma inglés simple que los no expertos puedan entender correctamente" ( Stevertigo et al 2005 ). Esto es particularmente importante en artículos especializados sobre temas oscuros. No deberíamos dividir la enciclopedia en secciones "accesibles" y "solo para expertos". pburka ( charla ) 16:30, 1 de septiembre de 2020 (UTC)
- Bueno, nuestros artículos tienen que ser accesibles para que la gente los lea. No creo que debamos intentar hacer que los artículos sean accesibles para las personas que no los leerán. ¿Cómo y por qué intentaríamos hacer que la síntesis enantioselectiva o el estimador M sea fácilmente comprensible para una audiencia completamente no especializada? Para que un lector termine buscando cualquiera de esos temas en primer lugar, deberá haber tenido cierto interés y familiaridad con los temas académicos más amplios. - Uanfala (charla) 19:15, 2 de septiembre de 2020 (UTC)
- Se supone que nuestros artículos deben ser "comprensibles para la mayor cantidad posible" y "escritos en un idioma inglés simple que los no expertos puedan entender correctamente" ( Stevertigo et al 2005 ). Esto es particularmente importante en artículos especializados sobre temas oscuros. No deberíamos dividir la enciclopedia en secciones "accesibles" y "solo para expertos". pburka ( charla ) 16:30, 1 de septiembre de 2020 (UTC)
- Soporte . La nominación resume bastante bien por qué sería una buena idea, con la conclusión clave de que la experiencia del lector es lo más importante aquí, y la experiencia del editor es una consideración secundaria. Y artículos como Actuario , con su incómoda inserción de referencias en y entre el texto, proporcionan el ejemplo perfecto de por qué ese estilo debería ser desaprobado. Por supuesto, esto no significa que rechacemos los envíos de cualquier persona o eliminemos texto, porque solo han proporcionado citas en el formato en línea. Simplemente significa que la regla arcana que prohíbe a los gnomos convertir tales citas en el formato estándar de nota al pie debe descartarse. Como punto final, se dijo anteriormente que los actuales arreglos permisivos evitan disputas porque los editores pueden simplemente hacer lo que quieran, y el cambio de formato está prohibido. Yo diría lo contrario: la estandarización en un formato es lo que realmente elimina las disputas, porque una vez que se establece ese formato, no hay base para tener que volver a discutir cuál debería usarse, incluso cuando dos editores habituales de un artículo no están de acuerdo. Saludos - Amakuru ( charla ) 15:11, 18 de agosto de 2020 (UTC)
- Apoyar la depreciación progresiva. Existe una gran cantidad de estilos de citas en detrimento de la coherencia visual. No veo ninguna razón por la que las citas entre paréntesis no puedan colocarse fácilmente dentro de las etiquetas de referencia. Si los editores quieren copiar en algún texto CC para un nuevo artículo, no detendría a otro editor al que le gusta trabajar en las citas para venir después y ponerlas en el estilo definido. - OHC ¡Dígame! 08:38, 19 de agosto de 2020 (UTC)
- Soporte Por una serie de razones ya mencionadas. Si realmente hay editores {potenciales} a los que les resulta un desafío técnico insuperable escribir en
Bloggs 2003
lugar de(Bloggs 2003)
, probablemente no van a durar mucho aquí de todos modos. Chuntuk ( charla ) 10:59, 19 de agosto de 2020 (UTC) - Apoye formalmente la preferencia por las citas al estilo de las notas al pie de página, oponga la desaprobación formal de las citas entre paréntesis en línea. Soporte para permitir / alentar a los gnomos a convertir citas entre paréntesis en notas al pie sin el requisito de agregar contenido, siempre que el artículo no esté en proceso de ser desarrollado por un editor que emplee citas entre paréntesis. Con respecto al Usuario: NSH001 y la conciencia de mi propia ignorancia potencial, los beneficios de usar citas entre paréntesis en lugar de notas al pie en el grupo de monstruos son todo menos obvios para mí. Además, afirmaría que el ejemplo de wikitexto citado en bloque de human shield en respuesta a User: Tony1 's support no impugna significativamente la legibilidad del lado de la edición de las citas con notas al pie de página, ya que tampoco hay una guía para que los editores definan sus referencias nombradas en el texto. de la prosa donde aparecen por primera vez, ni hacerlo sin espacios en blanco sin representación en los parámetros de llamada de la plantilla, aunque concederé fácilmente que la mayoría de los editores de hecho se involucran en ambas prácticas. No creo que haya ninguna razón por la que no podamos preferir las citas a pie de página y también pedir a los editores que traten de hacer que sus referencias sean lo suficientemente legibles para que la prosa del artículo pueda ser comprensible en la ventana de edición sin demasiado esfuerzo. <3 Folly Mox ( charla ) 20:48, 19 de agosto de 2020 (UTC)
- Tony1 hizo una afirmación sobre lo que pensaba que alejaba a los editores; Respondí por qué pensaba que eso era poco probable, y di una explicación mucho más probable de por qué los novatos son expulsados. Hay una buena razón por la que lo llamo el estilo de cita del montón de estiércol . Declaro en mi página de discusión por qué me ahuyentará si no se puede arreglar. Si casi me aleja, un editor con más de 14 años de experiencia, imagínense lo que va a pensar un novato. Me quedo porque todavía puedo trabajar en artículos que no están en el estilo del estercolero, y he desarrollado una herramienta (el script ETVP) que puedo usar para deshacerme del estercolero, aunque su uso está restringido por WP: CITEVAR y WP: CITESTYLE (como debería ser). Mi principal objetivo al responder a Tony fue corregir su afirmación sobre lo que aleja a los posibles editores. Sigo oponiéndome firmemente a la propuesta de desaprobar todo un estilo de cita válido y útil (en el proceso de anulación de políticas de larga data que se ha demostrado que funcionan), como me alegra ver que usted también lo hace. Eso no significa que esté en contra de las notas al pie, ni mucho menos (todavía es posible usar notas al pie sin crear un montón de estiércol). Todos los artículos que he escrito han usado notas a pie de página. Los autores deben usar el estilo adecuado para el tema, y eso puede ser entre paréntesis, referencias definidas en lista o en forma abreviada, o incluso una combinación de estos, si es sensato. Es posible que desee resaltar en negrita la parte "oponerse" de su respuesta, para mayor claridad. En el grupo de monstruos , el usuario Uanfala hace algunos comentarios útiles arriba. Alentar a los gnomos a que se conviertan entre paréntesis en otra cosa, sin primero obtener un consenso en la página de discusión, es una muy, muy mala idea, que solo conducirá a una pérdida de tiempo y una guerra de edición. - NSH001 ( conversación ) 22:58, 19 de agosto de 2020 (UTC)
- Soporte . Se utilizan en una minoría cada vez más pequeña de artículos y distraen mucho e inesperadamente en esos artículos. Debemos aspirar a un nivel básico de coherencia en la forma en que presentamos nuestros artículos al mundo. Esto, eso y lo otro ( charla ) 10:19, 21 de agosto de 2020 (UTC)
- Fuerte apoyo porque el formato en línea es disruptivo para el lector (la persona a la que existimos para servir), y probablemente más difícil que otros formatos para los editores (especialmente los más nuevos) para hacerlo bien; deberíamos apuntar a facilitar tanto la lectura como la edición; días felices, Lindsay Hola 10:57, 21 de agosto de 2020 (UTC)
- Comentar .
- Muchas de las contribuciones que veo aquí se basan en una mirada rápida y superficial al artículo del Actuario . Los problemas se pueden solucionar fácilmente mediante la edición normal, como lo describí en la charla: Actuario . Todos están tratando de curar el problema equivocado.
- Es una tontería prohibir un estilo de cita válido y útil por una razón equivocada.
- Las referencias entre paréntesis en realidad tienen algunas ventajas convincentes. He destacado algunos de ellos en mi contribución anterior.
- En algunos casos, las referencias entre paréntesis mejoran la apariencia del artículo.
- Aquí están algunos artículos que utilizan las referencias entre paréntesis: La caída problema del gato , el álgebra de Fréchet , álgebra gráfico , forma armónica Maass , forma modular Mock , grupo Monster , W-álgebra . Ninguno de estos mejoraría si se cambiaran a citas con superíndice. Ordenar tal cambio huele a totalitarismo estalinista / de la era soviética. Por no hablar de la colosal pérdida de tiempo que implica. Y, por cierto, intentar cambiar el estilo en esos artículos no sería fácil.
- Mi opinión sigue siendo que la referencia entre paréntesis es un estilo de cita infrautilizado y poco apreciado. No es mi estilo habitual o preferido, pero este RfC ha hecho que aprecie más sus ventajas. Ya lo estoy usando en parte y en una forma muy pequeña.
- Piense en las referencias entre paréntesis como una variante de la forma abreviada, a la que nadie aquí parece tener objeciones. Es muy parecido al formato corto de muchas formas (como lo demuestra el hecho de que las familias de plantillas {{ sfn }}} y {{ harv }} funcionan básicamente de la misma forma). El uso de paréntesis le brinda la ventaja de deshacerse de una sección completa al final y facilitar un poco el acceso a las citas completas. La compensación es el "costo" de una pequeña cantidad de texto adicional en el cuerpo del artículo. Ese "costo" se puede minimizar mediante una edición cuidadosa, sobre todo manteniendo las citas lo más lejos posible al final de las oraciones.
- Al igual que la forma abreviada (mira, te lo dije, ¡tiene mucho en común con la forma abreviada!), Te ofrece una lista bibliográfica de citas ordenada alfabéticamente, agradable y ordenada al final, en contraste con {{ reflist }} donde el orden es más o menos aleatorio (el orden en el que aparecen las citas en el wikitexto). - NSH001 ( conversación ) 13:26, 21 de agosto de 2020 (UTC)
- El soporte , el formato en línea es desordenado y menos accesible. No es necesario cambiar en masa los artículos existentes, simplemente no agreguemos más. Sofocar ( charla ) 15:39, 21 de agosto de 2020 (UTC)
- Fuerte apoyo . Las "citas" entre paréntesis son horribles y hostiles al lector, y las odio con cada fibra de mi ser. - ♠ Vami _IV † ♠ 18:46, 21 de agosto de 2020 (UTC)
- pero realmente el formato actual "cite", aunque lo uso para adaptarme al estilo existente cuando es conveniente. Cada uno de nosotros tiene sus propias preferencias muy fuertes, y juzgar por el tipo de formato que "odiamos" individualmente no es cooperativo ni productivo. DGG ( charla ) 03:18, 24 de agosto de 2020 (UTC)
- Soporte En ninguno de los pocos artículos que he visto que usan esto, las citas en línea han sido una mejora; son desorden. Creo que está bien mencionar la fuente como parte de la prosa ("El autor (2020) dice ...") cuando sea apropiado, pero "Esto es un hecho (Autor 2020)" y no se deben usar las citas de notas al pie estándar. . Reywas92 Talk 07:20, 22 de agosto de 2020 (UTC)
- Apoyar no introducirlos en nuevos artículos y mantener derechos adquiridos en artículos que ya usan citas entre paréntesis en línea .-- Esprit15d • charla • contribuciones 11:34, 24 de agosto de 2020 (UTC)
- Apoye no introducirlos en nuevos artículos, o al menos desalentar su uso, sino que los proteja en artículos que ya usan citas entre paréntesis. Creo que este es el compromiso que estaba esperando. Certes ( charla ) 12:06, 24 de agosto de 2020 (UTC)
- Continuar oponiéndome: si tuviera que recomendar un solo estilo, no solo permitiría, sino que recomendaría citas entre paréntesis para cualquier artículo que no sea el más complicado: son inmensamente más fáciles de escribir y los encuentro más fáciles de leer. Es obvio que no todo el mundo está de acuerdo; la mayoría de la gente parece preferir otros estilos, y creo que nuestro sistema de permitir cualquier estilo coherente tiene sus méritos. DGG ( charla ) 18:27, 25 de agosto de 2020 (UTC)
- No estoy de acuerdo con que las referencias entre paréntesis en línea sean inmensamente más fáciles de escribir. Las citas de etiquetas de referencia pueden ser tan simples como copiar y pegar una URL entre dos etiquetas de referencia y listo (lo sé, no se recomiendan las URL desnudas ...). Las citas en línea requieren algo en el texto principal y una entrada completa en la sección posterior al artículo. - HyperGaruda ( charla ) 20:25, 28 de agosto de 2020 (UTC)
- ¿Ha realizado alguna formación de nuevos editores? Supongo que no. Las referencias entre paréntesis (que no me gustan en absoluto) no requieren ningún conocimiento del marcado wiki, que es una gran barrera en sí misma para la mayoría de los nuevos editores. Johnbod ( charla ) 02:47, 29 de agosto de 2020 (UTC)
- No estoy de acuerdo con que las referencias entre paréntesis en línea sean inmensamente más fáciles de escribir. Las citas de etiquetas de referencia pueden ser tan simples como copiar y pegar una URL entre dos etiquetas de referencia y listo (lo sé, no se recomiendan las URL desnudas ...). Las citas en línea requieren algo en el texto principal y una entrada completa en la sección posterior al artículo. - HyperGaruda ( charla ) 20:25, 28 de agosto de 2020 (UTC)
- Support Lake Ptolomeo es un ejemplo de un AG que utiliza referencias entre paréntesis. Y se ve horrible y poco parecido a Wikipedia, como un periódico universitario. Incluso los lectores seguramente se preguntarán si han aterrizado en el sitio web equivocado cuando ven esto. SD0001 ( conversación ) 15:57, 28 de agosto de 2020 (UTC)
- La forma en que diría esto es que WP es tan conocido por un estilo confuso de citas y escritura, y una apariencia obsoleta y un diseño incómodo, que cualquier cosa simple y clara parece no ser WP. DGG ( charla ) 04:02, 29 de agosto de 2020 (UTC)
- ¿En serio? ¿Es ese tu mejor argumento? ¿Alguna nostalgia fuera de lugar por el desorden? - Francis Schonken ( charla ) 04:41, 29 de agosto de 2020 (UTC)
- Es discutible si el estilo entre paréntesis es "simple y claro" para cualquier persona que no sea académica. Vuelve a la cuestión de si escribimos WP para los expertos o para los lectores legos. Los expertos en la materia probablemente preferirían ver referencias entre paréntesis. Pero creo que la mayoría de los lectores no son académicos y no se han encontrado con este estilo, excepto en algunos artículos universitarios escritos hace tantos años.
- Dicho esto, las plantillas {{ harv }} y {{ sfn }} son sintácticamente muy similares, por lo que sería posible tener un gadget que haga que {{ sfn }} se muestren como {{ harv }} s (o viceversa) según la preferencia del usuario. SD0001 ( conversación ) 05:10, 29 de agosto de 2020 (UTC)
- Comentario No es de extrañar que pensara que el lago Ptolomeo se veía mal. Quien lo haya escrito incorrectamente puso las citas después de la puntuación. El resultado fue que todas las citas en línea parecían comenzar oraciones y cláusulas para las que no tenían absolutamente ninguna relevancia, y estaban desconectadas de las declaraciones que se suponía que debían respaldar, lo que hacía que todo fuera ilegible. Me sorprende que haya pasado GA en esa condición. De todos modos, lo arreglé aquí usando mi script ETVP. Creo que ahora se lee perfectamente bien, y las citas ahora respaldan las afirmaciones que se supone que deben hacer. Pero el punto principal que debería extraerse de esto es que sigo viendo a tantos editores que miran rápidamente y son superficiales y no logran identificar el problema real (y el problema real no son las citas entre paréntesis). - NSH001 ( conversación ) 05:03, 30 de agosto de 2020 (UTC)
- Pero eso es exactamente lo que hacen muchos de nuestros lectores: echar un vistazo rápido y superficial, y los artículos con paréntesis en línea en azul, indistinguibles de los enlaces, reducen la legibilidad y accesibilidad del artículo. Retswerb ( charla ) 06:20, 31 de agosto de 2020 (UTC)
- No, no, no, no entendiste por completo. Aquí estoy hablando de que los editores de un RfC son superficiales y, como resultado, llegan a una conclusión equivocada. El punto es que cualquier problema con Actuary se puede solucionar mediante la edición normal, sin deshacerse de las citas entre paréntesis. El problema no son las citas entre paréntesis, pero la gente aquí sigue respondiendo como si lo fuera. Pero dado que plantea el punto de que (supuestamente) las citas entre paréntesis reducen la legibilidad, eso tampoco es cierto en general. Una cita entre paréntesis (PC) al final de un párrafo nunca interrumpe el texto (y de hecho es una ligera mejora); de manera similar, un PC al final de una oración es poca o ninguna interrupción. Una PC de la forma "(Smith 1990) encontró que ..." también se lee perfectamente bien. Reconozco que una PC en medio de una oración a veces puede ser intrusiva, pero una edición cuidadosa generalmente puede evitar eso. Además, el atractivo o no del formato es una cuestión de gusto u opinión. Y ciertamente no justifica una prohibición estalinista / totalitaria de un estilo de cita válido y útil. - NSH001 ( conversación ) 08:20, 31 de agosto de 2020 (UTC)
- Pero eso es exactamente lo que hacen muchos de nuestros lectores: echar un vistazo rápido y superficial, y los artículos con paréntesis en línea en azul, indistinguibles de los enlaces, reducen la legibilidad y accesibilidad del artículo. Retswerb ( charla ) 06:20, 31 de agosto de 2020 (UTC)
- Comentario No es de extrañar que pensara que el lago Ptolomeo se veía mal. Quien lo haya escrito incorrectamente puso las citas después de la puntuación. El resultado fue que todas las citas en línea parecían comenzar oraciones y cláusulas para las que no tenían absolutamente ninguna relevancia, y estaban desconectadas de las declaraciones que se suponía que debían respaldar, lo que hacía que todo fuera ilegible. Me sorprende que haya pasado GA en esa condición. De todos modos, lo arreglé aquí usando mi script ETVP. Creo que ahora se lee perfectamente bien, y las citas ahora respaldan las afirmaciones que se supone que deben hacer. Pero el punto principal que debería extraerse de esto es que sigo viendo a tantos editores que miran rápidamente y son superficiales y no logran identificar el problema real (y el problema real no son las citas entre paréntesis). - NSH001 ( conversación ) 05:03, 30 de agosto de 2020 (UTC)
- La forma en que diría esto es que WP es tan conocido por un estilo confuso de citas y escritura, y una apariencia obsoleta y un diseño incómodo, que cualquier cosa simple y clara parece no ser WP. DGG ( charla ) 04:02, 29 de agosto de 2020 (UTC)
- ¡Gran ejemplo! Esto parecería violar WP: OVERLINK para mí: hay tanto azul repitiendo los nombres de los autores, el desorden hace que sea más difícil hojear o leer el artículo. Nadie necesita leer los nombres de los autores una y otra vez mientras intentan leer el contenido realmente significativo. Y no, la ubicación de la puntuación no es el problema, ¡todavía se ve horrible! ¿Cómo en el mundo son confusas las notas numeradas al pie de página? Reywas92 Talk 02:27, 1 de septiembre de 2020 (UTC)
- Apoyo : Me topé con esta discusión después de mirar con asombro a Sepermeru . Sentí que todo el conjunto de citas se usaba como referencia en línea, lo que a veces me hacía preguntarme dónde continuaría el texto principal. Como mínimo, debería levantarse la prohibición de la conversión de estilo no discutida a partir de referencias entre paréntesis en línea. No lloraría si las referencias entre paréntesis en línea estuvieran completamente desaprobadas, pero podría ser un paso demasiado lejos para algunos. - HyperGaruda ( charla ) 20:14, 28 de agosto de 2020 (UTC)
- Soporte : los artículos que utilizan este estilo arcaico son difíciles de leer y de verificar. ¡Me sentí así cuando era estudiante y nada ha cambiado! Simplemente use citas en línea con etiquetas de referencia como la gran mayoría de los artículos. Muñeco de nieve gigante 20:44, 29 de agosto de 2020 (UTC)
- Comentario No, no son "difíciles de verificar". Siempre que hagan un uso adecuado de la familia de plantillas {{ harv }} y exista un destino adecuado en la bibliografía, en realidad son un poco más fáciles de verificar. - NSH001 ( conversación ) 09:08, 30 de agosto de 2020 (UTC)
- Soporte por estandarización, consistencia, facilidad de mantenimiento y legibilidad. - HELL KNOWZ ▎ TALK 20:56, 29 de agosto de 2020 (UTC)
- Soporte : debe desalentarse en artículos nuevos; y los editores deben sentirse libres de realizar la transición de artículos existentes. Las referencias son fáciles de programar y actualizar en masa, y mantienen el texto limpio. No deberíamos permitir que las limitaciones que existen en el papel físico dicten lo que hacemos en una enciclopedia en línea donde la tecnología se puede utilizar para proporcionar características aún mejores. - Starforce 13 21:03, 29 de agosto de 2020 (UTC)
- Soporte VisualEditor y otras herramientas han mejorado la capacidad de agregar / editar referencias sin usar las abreviaturas en línea. Thosbsamsgom ( charla ) 21:11, 29 de agosto de 2020 (UTC)
- Soporte por Thosbsamsgom. Había una razón para permitir diferentes estilos antes de VisualEditor y las herramientas relacionadas hacían que fuera trivialmente fácil crear citas en el formato estándar. Ahora bien, no existe tal razón y existen varias razones para exigir coherencia. El más fuerte es la facilidad de verificación: incluso una referencia simple, sin plantilla, formateada con
ref
etiquetas es mucho más fácil de verificar que una referencia entre paréntesis en línea. AleatoryPonderings ( charla ) 21:20, 29 de agosto de 2020 (UTC)
- Apoyo - Tengo una preferencia personal de no ver citas entre paréntesis, pero si fuera solo mi preferencia personal, no estaría votando aquí. La razón por la que estoy participando en el campo de apoyo es indirecta: la barra de herramientas de citas en el Editor visual (o como se llame en estos días) que permite la creación y edición fáciles de citas ha sido, en mi experiencia, el desarrollo más importante para el proceso de aprendizaje del nuevo usuario. Es decir, facilita las citas. Tiene importantes limitaciones e inconvenientes en la actualidad (no me hagas empezar con la denominación ": 0", por ejemplo), pero es un gran paso en la dirección correcta. Yo apoyaría la mayoría de las medidas que intentan estandarizar la forma en que se ingresan las citas . Sin embargo, eso no quiere decir que deba haber inflexibilidad en la forma en que mostramos las citas. Cuanto más podamos estandarizar el proceso de entrada, más fácil será para los nuevos usuarios y más fácil será desarrollar herramientas que funcionen: para proporcionar flexibilidad en la visualización, para agilizar procesos complicados (incluso para editores experimentados), para corregir errores automáticamente , para hacer bots más poderosos, etc. Sé que esta no es una propuesta de estandarización, pero es un paso en la dirección correcta, lejos de un proceso que está muy alejado de la forma en que la gran mayoría de los editores hacen las cosas (y la forma en que todos nuestros materiales de capacitación para nuevos usuarios dicen que lo haga). - Hablar de las rododendritas \\ 21:20, 29 de agosto de 2020 (UTC)
- Soporte : no me siento mal por esto, pero lo apoyo porque los paréntesis en línea no reúnen las referencias en una sección separada que se puede navegar fácilmente. Beyond My Ken ( charla ) 21:26, 29 de agosto de 2020 (UTC)
- De hecho, eso es exactamente lo que hacen . Johnbod ( charla ) 21:50, 29 de agosto de 2020 (UTC)
- Soporte : las notas a pie de página respaldadas por software son más fáciles de leer y acceder, brindan información más clara y tienen un aspecto mucho menos desordenado que los parantéticos. Siempre que las plantillas como Template: Sfn y Template: Harv todavía estén en uso, creo que alejarse de los parantéticos de texto en línea es una gran idea. Noahfgodard ( charla ) 21:33, 29 de agosto de 2020 (UTC)
- @ Noahfgodard : No entiendo tu comentario. ¿Apoya desaprobar las referencias cortas entre paréntesis siempre que se sigan utilizando las plantillas que generan referencias cortas entre paréntesis? Eso no tiene sentido. Tenga en cuenta que la redacción de la RFC no distingue entre referencias como (Autor 2020) (una referencia que en la mayoría de los casos desordena el texto y sería mejor como nota al pie), referencias como "Autor1 (2018) escribió que ... pero Autor2 (2020) en desacuerdo, escribiendo ... "(una referencia entre paréntesis donde el nombre del autor es parte del texto del artículo y es presumiblemente relevante como contenido en lugar de simplemente como una referencia), y referencias que usan sfn (referencias entre paréntesis dentro de las notas al pie de página), y aclaraciones posteriores del proponente han indicado hostilidad hacia todas estas formas). - David Eppstein ( charla ) 01:44, 31 de agosto de 2020 (UTC)
- @ David Eppstein : Para citar al proponente, "No propongo que prohibamos TODAS las referencias entre paréntesis. Simplemente propongo que no usemos paréntesis de texto en línea, no basados en software. Esta NO es una propuesta para prohibir Template: sfn , o Plantilla: Harv (siempre que esté correctamente anidado en una etiqueta de referencia) ". Por lo tanto, la tercera opción que proporciona es adecuada, pero los parantéticos en línea no lo son. Dicho esto, parece que quizás yo (y el proponente) malinterpretamos el uso de Template: Harv, ya que yo (apoyamos) el uso / función de Template: sfn, pero probablemente no el de Template: Harv. Noahfgodard ( charla ) 03:25, 31 de agosto de 2020 (UTC)
- @ Noahfgodard : No entiendo tu comentario. ¿Apoya desaprobar las referencias cortas entre paréntesis siempre que se sigan utilizando las plantillas que generan referencias cortas entre paréntesis? Eso no tiene sentido. Tenga en cuenta que la redacción de la RFC no distingue entre referencias como (Autor 2020) (una referencia que en la mayoría de los casos desordena el texto y sería mejor como nota al pie), referencias como "Autor1 (2018) escribió que ... pero Autor2 (2020) en desacuerdo, escribiendo ... "(una referencia entre paréntesis donde el nombre del autor es parte del texto del artículo y es presumiblemente relevante como contenido en lugar de simplemente como una referencia), y referencias que usan sfn (referencias entre paréntesis dentro de las notas al pie de página), y aclaraciones posteriores del proponente han indicado hostilidad hacia todas estas formas). - David Eppstein ( charla ) 01:44, 31 de agosto de 2020 (UTC)
- Soporte : alejarse de las citas entre paréntesis en línea haría que el formato sea más consistente y la verificación / uso más fácil. - t • c 21:34, 29 de agosto de 2020 (UTC)
Flori4nK
- Oponerse por Wugapodes, DGG y varios otros. - SchroCat ( charla ) 21:52, 29 de agosto de 2020 (UTC)
- Oponerse , principalmente por las razones articuladas por David Eppstein. Hay varias situaciones en las que el uso de la notación de referencia entre paréntesis es enciclopédica preferible y aconsejable. Eliminar esa opción en aras de la uniformidad general sería un error. Quizás estaría cautelosamente a favor de algo como lo que propone xaoflux, pero solo suponiendo que se mencionen varias condiciones condicionales. Nsk92 ( charla ) 22:03, 29 de agosto de 2020 (UTC)
- Soporte , parece que este estilo es más difícil de leer en las traducciones. Semper Fi! FieldMarine ( charla ) 22:04, 29 de agosto de 2020 (UTC)
- El soporte , los hipervínculos entre referencias y notas a pie de página facilitan la evaluación de la validez. Más fácil de leer. BennH ( charla | contribuciones ) 09:04, 31 de agosto de 2020 (UTC)
Descanso arbitrario 2 (citas)
- Fuerte apoyo : como otros han señalado, solo mire los artículos sobre Sepermeru y actuarios para ver lo horrible que se ve esto. Además, si todas las citas de un artículo están incluidas en
etiquetas, es mucho más fácil procesar las referencias mediante secuencias de comandos. También me sorprende mucho que alguien se oponga a esto. Brad ( charla ) 21:18, 29 de agosto de 2020 (UTC)
- Comentario Incorrecto en ambos aspectos. El artículo de Sepermeru no tiene nada que ver con el estilo entre paréntesis (o cualquier otro estilo), y los "problemas" de Actuary se pueden solucionar mediante la edición normal, como ya he señalado, más de una vez. - NSH001 ( conversación ) 05:45, 30 de agosto de 2020 (UTC)
- Oponerse . Muchos editores nuevos, particularmente académicos, están acostumbrados a usar citas entre paréntesis. Obligarlos a aprender un estilo diferente, ya sea desde el principio o después de que otro editor o bot haya cambiado lo que escribieron para usar un estilo diferente, sería una barrera más de entrada y ya tenemos demasiadas barreras. Clayoquot ( discusión | contribuciones ) 22:02, 29 de agosto de 2020 (UTC)
- Soporte en aras de la coherencia y como la versión utilizada en una menor cantidad de artículos. Steel1943 ( charla ) 22:43, 29 de agosto de 2020 (UTC)
- Soporte . Está bien tener un estándar y este cambio permitiría que la prosa en general sea más fácil para el lector. No apoyo la aplicación de una manera draconiana que desaliente a los editores sin experiencia a contribuir. Airborne84 ( conversación ) 22:46, 29 de agosto de 2020 (UTC)
- Fuerte oposición . deberíamos dar la bienvenida a las citas en cualquier forma en la enciclopedia que cualquiera pueda editar. Feoffer ( charla ) 22:48, 29 de agosto de 2020 (UTC)
- Opónganse (por ahora) principalmente por David E. y DGG, pero el "por ahora" es cuando el editor visual está disponible en cada página y la inserción y edición de notas al pie es fácil para los nuevos usuarios, puedo ver que revisando esta discusión. Pero en la actualidad, la forma de editar una nota a pie de página sigue siendo demasiado difícil, mientras que la cita entre paréntesis con bibliografía es mucho más fácil. - Michael Scott Cuthbert (charla) 22:59, 29 de agosto de 2020 (UTC)
- Respaldo firmemente Esta propuesta ayudará a estandarizar el contenido de nuestro proyecto. No creo que esta propuesta deba o hará que el trabajo de un editor se revierta si usa un estilo de cita entre paréntesis en línea. En su lugar, puede aparecer otro editor y hacer una wikificación. Los académicos, las personas y los estudiantes que escriben artículos fuera de la wiki deben adherirse a las preferencias de las personas a las que envían sus artículos para su publicación o evaluación. Creo que se espera que Wikipedia tenga su propio estilo y les pedimos a los editores que publican con nosotros que se adhieran a él o que esperen que alguien venga y lo "arregle". El argumento más convincente para su eliminación es que las citas entre paréntesis hacen que los artículos sean más difíciles de leer debido al "desorden" adicional. Las citas numeradas son menos engorrosas y deben fomentarse para nuestro proyecto. Z1720 ( conversación ) 23:03, 29 de agosto de 2020 (UTC)
- El soporte simplifica el sistema de referencia y los hipervínculos son más intuitivos para lectores no académicos. Saludos, 1292simon ( charla ) 23:07, 29 de agosto de 2020 (UTC)
- Oponerse por Yngvadottir. - JBL ( charla ) 23:08, 29 de agosto de 2020 (UTC)
- Fuerte apoyo . Hay muchos más lectores de Wikpedia que editores, y muchos más lectores que solo quieren leer el artículo para obtener información y no estudiarlo como si estuviera en una revista científica que solicita una revisión por pares, y estoy bastante seguro que los lectores directos son más numerosos que los verificadores de citas concienzudos. [ cita requerida ] . De WP: NOT : "Los artículos de Wikipedia no deben leerse como ... Lenguaje académico". Yo diría aún más: cuanto más académicamente abstruso es un tema, más debemos ayudar a la comprensión de un lector inteligente, y una experiencia de lectura fluida es esencial para eso. Incluso si comprende su significado (¿y cuántos lectores realmente lo hacen?), La cita entre paréntesis es un registro enrollado en el camino de la comprensión y puede romper el análisis mental de una oración o párrafo bien escrito. Para ser honesto, siempre he odiado los números pequeños en superíndice azul porque son como una pequeña espina en mi globo ocular; incluso esas pequeñas cosas se "leen" mentalmente y rompen la prosa (sí, sé que podría hacerlas invisibles con CSS). Es más, apoyo alentar a los editores a convertirlas a citas de estilo cuando las encuentren. ¿He mencionado cuánto los desprecio? David Brooks ( charla ) 23:13, 29 de agosto de 2020 (UTC)
- Se oponen por Wugapodes sino también principalmente como esto es inaplicable y, en general estoy en contra de los no-políticas imposibles de cumplir. No creo que haya leído el MOS una vez en mi tiempo como editor y tengo 11 GA y una lista de destacados a mi nombre (menos de muchos, pero tampoco es nada). Cualquiera que sea un escritor lo suficientemente competente que quiere usar citas entre paréntesis las va a usar de todos modos y está bien . Este cambio no tendría un impacto real en la forma en que las personas escriben artículos porque 1) la mayoría de las personas no lo usan de todos modos y 2) IAR se usa mejor en cosas de tipo MOS, que es, por lo que las personas que quieren seguir usándolo si se ajusta a su tema de todos modos. Tl; dr: esto sería inaplicable y no es lo suficientemente común ahora, donde incluso si se hiciera cumplir, tendría algún impacto. TonyBallioni ( charla ) 23:15, 29 de agosto de 2020 (UTC)
- Soporte en beneficio del lector típico. Tdslk ( charla ) 23:16, 29 de agosto de 2020 (UTC)
- Soporte según la mayoría de los anteriores. Las citas en línea interrumpen la fluidez de la lectura de un texto y yo personalmente siempre he utilizado el Manual de estilo de Chicago siempre que ha sido posible. Dicho esto, no creo que debamos ser súper dogmáticos al respecto. Cuando existan artículos con citas en línea, si hay un argumento razonable de por qué son los mejores en esa situación y están respaldados por un fuerte consenso local, déjelos ser. Pero creo que, en general, debería desalentarse su uso. - Ad Orientem ( charla ) 23:27, 29 de agosto de 2020 (UTC)
- Oponerse por CITEVAR. No veo una razón convincente para esto y temo que disuadirá a los nuevos editores que están acostumbrados a este estilo. - Tom (LT) ( conversación ) 23:35, 29 de agosto de 2020 (UTC)
- Soporte Sí, es casi seguro que las citas en este estilo dificulten la lectura de un artículo. 41618CCEC ( conversación ) 23:37, 29 de agosto de 2020 (UTC)
- Oponerse No vale la pena forzarlo antes de lo que naturalmente lo haría, lo que esperaríamos que hiciera si fuera necesario. Usedtobecool ☎️ 23:41 , 29 de agosto de 2020 (UTC)
- Oponerse El uso de un cierto estilo de cita debe ser opcional, no forzado a otros colaboradores simplemente porque a otro editor no le gusta o no sabe cómo implementarlo en los artículos. O parece "mejor" o "más organizado" ... lo que sea que eso signifique. Lo único que importa es que el contenido esté respaldado por una cita. Estoy seguro de que si esto pasa, se producirá otra discusión similar sobre el estilo de la era a través de WP: ERA, donde esta comunidad decide obligar a otros editores a usar solo un estilo de la era, y estoy seguro de que tal discusión será contraproducente. Prefiero el estilo "académico" ... lo que sea que eso signifique. Gente, si no quieren un artículo de estilo académico, está la Wikipedia en inglés simple . Jerm ( charla ) 23:48, 29 de agosto de 2020 (UTC)
- Oponerse a Wikipedia no debería dictar que los estilos de citas perfectamente finos son inaceptables sin una buena razón, y las únicas razones que he visto es que a los editores individuales no les gusta y por coherencia; Sin embargo, si realmente quisiéramos coherencia sobre la elección individual, exigiríamos un estilo específico. No deberíamos dificultar la contribución de los académicos recién llegados, y todo lo que veo de esta propuesta es un paso en esa dirección. Zoozaz1 ( charla ) 23:50, 29 de agosto de 2020 (UTC)
- Fuerte apoyo : Si bien la mayoría de los artículos obviamente usan un estilo de referencia de nota al pie, los pocos que usan referencias entre paréntesis parecen discordantes, creo que tanto para los lectores como para los editores. Para los lectores, interrumpe el flujo de texto y es enormemente inconsistente con la mayoría de los artículos. Como editor, me molestan porque (1) es difícil rastrearlos en cualquier artículo más largo que un talón, (2) a menudo están rotos (por ejemplo, solo el apellido y el año de publicación del autor, pero no la nota al pie correspondiente), ( 3) El sistema de MediaWiki y nuestras plantillas de citas son más flexibles mediante el uso de la abstracción , (4) fomentan la omisión de un número de página y (5) funcionan bien para libros y artículos de revistas, pero no para sitios web ( es decir ), que representan más del 90% de las fuentes que encuentro sobre todos los temas fuera de las artes liberales y la medicina. Para aquellos preocupados por desanimar a los nuevos editores, les reiteraría que la propuesta anterior es para reemplazar las referencias entre paréntesis con las estándar basadas en notas al pie; no hay necesidad de atacar a los editores que aportan contenido con referencias entre paréntesis. - 00:06, 30 de agosto de 2020 (UTC)
{{cite web}}
voidxor - Apoyo Me inclino por la estandarización para que la enciclopedia se vea más cohesionada y reconocible para el lector. Este estilo rara vez se usa y se ve horrible. Cuando vi por primera vez un artículo con estas citas, lo primero que pensé fue que estaba en el sitio equivocado o que las citas de la página se mostraban incorrectamente. MB 00:12, 30 de agosto de 2020 (UTC)
- Soporte . Torpe y desordenado. ¡Adiós, paréntesis! 👋 —Galleta en jefe :-) ( / tɔːk / - / ˈkɒntɹɪbs / ) 00:16, 30 de agosto de 2020 (UTC)
- Soporte . Consulta Actuario para ver qué tan horrible se ve. Moriori ( charla ) 00:22, 30 de agosto de 2020 (UTC)
- Sí, eso es bastante torpe. Realmente deberíamos desalentar su uso. - Ad Orientem ( charla ) 00:40, 30 de agosto de 2020 (UTC)
- @ Moriori y Ad Orientem : ¿ Y Aristóbulo yo ? Jerm ( charla ) 00:58, 30 de agosto de 2020 (UTC)
- Esto se ve bien. Esto no utiliza citas entre paréntesis ... Reywas92 Talk 02:38, 1 de septiembre de 2020 (UTC)
- @ Moriori y Ad Orientem : ¿ Y Aristóbulo yo ? Jerm ( charla ) 00:58, 30 de agosto de 2020 (UTC)
- Sí, eso es bastante torpe. Realmente deberíamos desalentar su uso. - Ad Orientem ( charla ) 00:40, 30 de agosto de 2020 (UTC)
- Soporte . Somos una enciclopedia en línea , adoptemos eso. Popcornfud ( charla ) 01:20, 30 de agosto de 2020 (UTC)
- Soporte : se ven horribles y en mi humilde opinión no deberían aparecer en artículos a menos que sea absolutamente necesario. De acuerdo con lo anterior, son confusos y hacen que leer artículos sea un trabajo difícil. - Davey 2010 Talk 01:33, 30 de agosto de 2020 (UTC)
- Soporte : no somos una revista académica y no tenemos motivos para parecernos una. Debe esperarse cierta coherencia con nuestro estilo para facilitar su uso. Me doy cuenta de que esto puede requerir algunos ajustes para los nuevos editores provenientes de la academia; si se pueden crear algunos recursos para facilitar su transición, imagino que valdría la pena invertir el esfuerzo. Al final, nuestros usuarios se beneficiarán de una experiencia de lectura constante en todos nuestros artículos. Radagast ( charla ) 02:04, 30 de agosto de 2020 (UTC)
- Oponerse : lo importante es la cita, no el estilo. Si no se prefieren las citas entre paréntesis para un artículo, se pueden reformatear al estilo preferido. Personalmente, odio la plantilla de citas y la encuentro muy difícil de usar, por lo que debe ser aún peor para los editores sin experiencia. Permítales tener sus citas entre paréntesis. MaxBrowne2 ( charla ) 02:20, 30 de agosto de 2020 (UTC)
- Oponerse totalmente a la desaprobación, pero apoyar la actualización de WP: referencias entre paréntesis para fomentar la conversión de las citas entre paréntesis existentes al sistema de notas al pie con soporte de software (según Alsee). Pteryx de armadillo 02:31, 30 de agosto de 2020 (UTC)
- Soporte , aunque ya rara vez veo esto en Wikipedia. De todos modos, el estilo entre paréntesis es propenso a los juegos, es desordenado e interrumpe el flujo de información y texto. Una de las razones por las que Wikipedia tiene el respeto que tiene ahora es por nuestro uso de citas con notas al pie de página que se pueden verificar instantáneamente y generalmente en las que se puede hacer clic (y salvo las etiquetas de "cita necesaria"). Las citas entre paréntesis son obviamente un paso atrás hacia referencias perezosas, distractoras y menos precisas, y no deben tolerarse en este momento. Softlavender ( charla ) 02:35, 30 de agosto de 2020 (UTC)
- Soporte Esta no es una publicación en papel, por lo que no es necesario adherirse al estilo de las revistas en papel, y crea un cuerpo de texto más limpio y legible. No rechazaría el envío de un artículo si así es como se envió, pero lo convertiría para usar {{ harv }} dentro de {{ sfn }} bastante pronto. (No es que sea necesariamente un fan de ellos, tampoco, ya que requieren múltiples ediciones de añadir tanto en la nota al pie y la referencia bibliográfica, y para el lector necesita varios clics para encontrar el ref completo, pero estoy divagando.) Oknazevad ( hablar ) 03:02, 30 de agosto de 2020 (UTC)
- Apoyo Me parece un estilo bastante discordante. Funciona, si. Pero no es bueno para la legibilidad. No me estoy comprando el argumento de que "duele a los nuevos editores", ya que un editor experimentado puede simplemente decirles que lo coloquen en una etiqueta de referencia, lo cual no es tan difícil de hacer. - Escarabajo de Indy ( conversación ) 03:46, 30 de agosto de 2020 (UTC)
- Soporte - Leyó la página y algunas de las páginas mencionadas y acepta que las páginas se ven desordenadas y que el estilo de las citas hace que las páginas sean más difíciles de leer. Ni siquiera puedo imaginar cómo se verá a los lectores. QueerFilmNerd talk 04:00, 30 de agosto de 2020 (UTC)
- Opónganse , según el argumento de Mike Christie: "Si esta forma de citación está desapareciendo, déjela morir por sí sola; si no es así, es porque a algunos editores les gusta". SarahSV (charla) 04:04, 30 de agosto de 2020 (UTC)
- Apoyo a la coherencia. La apariencia estandarizada es algo bueno. Cas Liber ( charla · contribuciones ) 04:27, 30 de agosto de 2020 (UTC)
- Soporte - Oh hombre, no he tenido que usar esa mierda en mucho, mucho tiempo e incluso que era demasiado reciente. No funciona bien para una enciclopedia en línea como lo demuestra la página de ejemplo y debe desalentarse por la fuerza. Es un flaco favor para el lector. PackMecEng ( charla ) 04:33, 30 de agosto de 2020 (UTC)
- Fuerte apoyo . Este ya es el caso en general, excepto en algunas áreas temáticas específicas, y es mucho más fácil de leer. No creo que nadie esté argumentando que las citas en línea son peores que ninguna cita, o que los artículos se rechacen porque tienen citas en línea, pero nadie debería tener que discutir el punto si quiere convertir las citas en línea al formato adecuado. . Frickeg ( charla ) 04:37, 30 de agosto de 2020 (UTC)
- Oponerse : lo importante no es el estilo de la cita, sino que se citan las declaraciones. Algunos colaboradores se sienten más cómodos con las referencias entre paréntesis en línea . Darles la libertad de usarlo fomenta sus contribuciones. Tener más editores que escriban más contenido sirve al WP: READER de una manera más significativa que lo que lo haría un estilo de cita consistente en todos los artículos. Algunos temas son más claros con referencias entre paréntesis en línea que con etiquetas de referencia. Si el consenso es que hacen que un artículo en particular sea más difícil de leer, se puede cambiar el estilo de cita de ese artículo. Pero un estilo de cita no debe desaprobarse simplemente por motivos de preferencia personal. - Worldbruce ( charla ) 04:43, 30 de agosto de 2020 (UTC)
- Enérgicamente opuesto La referencia entre paréntesis es muy superior tanto para los lectores como para los editores. (1) Los lectores ven inmediatamente el autor y la fecha y, a menudo, el número de página. Probablemente conocerán al autor. Ver la fecha indica la antigüedad de la información. Dada esta información, es muy probable que conozcan de inmediato la fuente. (2) Para los editores, la referencia está contenida de forma ordenada y concisa en el texto, lo que facilita ver dónde comienza y termina. El otro estilo puede durar cientos de caracteres, lo que dificulta que el editor vea dónde comienza y termina, lo que dificulta mucho la edición de esa sección de texto. Escribí sobre esto en mi página de usuario hace años, consulte Usuario: Bubba73 # Why_I_like_Parenthetical_referencing_ (also_known_as_the_author-date_system_and_Harvard_Referencing) . Bubba73 ¿ Me estás hablando? 04:46, 30 de agosto de 2020 (UTC)
- @ Bubba73 : Esta reacción me confunde, porque siento que está planteando la pregunta de quién es un lector "típico" de Wikipedia y qué es lo que quiere. Algunos de tus argumentos:
Los lectores ven inmediatamente el autor y la fecha y, a menudo, el número de página.
- De acuerdo, pero me parece extraño ver que lo caracteriza como positivo. "La mayoría de los lectores" (es decir, laicos - el "lector promedio" que no es académico) no quieren que su lectura sea interrumpida con detalles irrelevantes (para ellos) como el nombre del autor al que se hace referencia a una afirmación.
Probablemente conocerán al autor.
- Eso es simplemente falso. El lector medio no está familiarizado con los autores de los trabajos de investigación que se citan en línea en el texto del artículo en Wikipedia. El lector medio no está tan inmerso en el mundo académico que cada vez que se resfría, estornuda con pana.
Ver la fecha indica la antigüedad de la información.
- Ese es un buen punto. Me pregunto cuán interesado está realmente el "lector promedio", incluso en esa información, pero es un argumento (tibio) para las citas entre paréntesis.
Dada esta información, es muy probable que conozcan de inmediato la fuente.
- Ahora volvemos a ser patentemente falso. ¿¡Quiénes son estas personas de las que estás hablando !? El "lector medio" con el que tengo experiencia no tiene absolutamente ninguna familiaridad con los escritos de "D'Arcy 2005", "Krutov 2006" o "Bader & Gold 2003", para elegir tres ejemplos aleatorios de Actuary . ... Esas combinaciones de nombre y año no me dicen nada en absoluto, puedo decirlo con seguridad. ¿Son importantes para ti? (No "¿los encuentras útiles?" O "¿quieres que sean visibles en el texto?", Lo hemos establecido. Estoy preguntando, ¿esos identificadores por sí solos te dicen algo sobre las obras a las que se hace referencia? - Aparte de la antigüedad de la información, ya te di esa.)
- Simplemente parece que al menos uno de nosotros está proyectando bastante de su punto de vista personal sobre esta idea del visitante "promedio" de hombre de paja en Wikipedia. (Quiero decir, puedo decir que definitivamente soy culpable de esto hasta cierto punto ...) Quizás lo que necesitamos aquí es una imagen objetiva de la audiencia principal de Wikipedia. Para considerar esta propuesta y su impacto en los lectores de Wikipedia (a diferencia de su comunidad de autores / editores) en el marco de referencia adecuado, es importante comprender cómo las personas consumen el contenido del sitio y qué esperan de él. - FeRDNYC ( charla ) 09:38, 30 de agosto de 2020 (UTC)
- En cuanto a conocer al autor de la fuente, sí, eso generalmente se aplica a la lectura de un artículo en un área que conoces. Por ejemplo, si se trata de historia, es posible que sepa quiénes son los historiadores destacados. Bubba73 ¿ Me estás hablando? 15:29, 30 de agosto de 2020 (UTC)
- FeRDNYC, no creo que una enciclopedia con seis millones de artículos pueda tener una única audiencia objetivo coherente. Si bien las declaraciones de Bubba73 ciertamente no se aplican a los tipos más comunes de los lectores, que en gran parte no se aplican a los lectores que visitan los tipos especializados de artículos que normalmente se utilizan referencias entre paréntesis ( actuario siendo una excepción notable). - Uanfala (conversación) 12:48, 30 de agosto de 2020 (UTC)
- Soporte Si bien casi ningún artículo usa este estilo, ya no estamos en la década de 1970. Esta es la World Wide Web, donde podemos tener técnicas 'nuevas' y más fluidas como el abastecimiento en línea. Eche un vistazo doloroso a las referencias entre paréntesis en acción en Actuary . ThatMontrealIP ( charla ) 05:01, 30 de agosto de 2020 (UTC)
- Apoyo Aquellos que dicen que el estilo de las citas no es importante están equivocados. Wikipedia en sí es una herramienta para explorar otras fuentes y leer más sobre un tema para obtener detalles que podrían no estar incluidos o no ser apropiados para un artículo de Wikipedia. Además, es antiguo, arcaico y está destinado a ser utilizado en texto físico, no en línea. Utilizar plantillas y el software de Wikipedia es una opción mejor, más limpia, más adaptable y más optimizada. Nihlus 05:19, 30 de agosto de 2020 (UTC)
- Fuerte apoyo es el estilo de cita más disruptivo que permitimos actualmente en términos de flujo de lectura. Debería estar en desuso. Peacemaker67 ( haz clic para hablar conmigo ) 05:24, 30 de agosto de 2020 (UTC)
- Oponerse . Si bien también odio el estilo de las citas entre corchetes y a menudo me confunde, me llevo bien a medida que leo más el artículo. La gente tiene diferentes estilos, no puedes obligarlos a usar simplemente CS1 o CS2 o CS100, ¿sabes a qué me refiero? Al permitir más estilos de citas en Wikipedia, permitimos que más personas con diferentes antecedentes de citas editen, aumentando así la diversidad y accesibilidad de Wikipedia en términos de quién puede editar. En general, no veo cómo su desaprobación aumentaría el número de lectores. Gerald WL 05:30, 30 de agosto de 2020 (UTC)
- Totalmente compatible . Como se muestra la referencia completa al pasar el mouse, el estilo de cita entre paréntesis no es necesario en absoluto. - BhagyaMani ( charla ) 06:09, 30 de agosto de 2020 (UTC)
- Comente sobre una imagen más amplia. Anteriormente escribí sobre continuar apoyando el estilo de citas entre paréntesis limitado a las disciplinas que los usan comúnmente, una idea que, afaics, recibió cero tracción en este RfC. En Wikipedia se ofrece una lista de tales disciplinas : Referencia entre paréntesis # Pros y contras frente a otros sistemas de referencia : "... humanidades, sociedad, artes y cultura ..." Al mirar esa sección de la guía, me parece que falta una "estafa". Las citas entre paréntesis se utilizan en estas disciplinas principalmente al escribir un ensayo u otro tipo de contribución al campo sobre algo que aún no se había escrito antes . En otras palabras, cuando el autor tiene que demostrar un punto. Esto contrasta con lo que estamos haciendo en Wikipedia: no tenemos nuevos puntos que destacar ( WP: NOR ). Entonces, una contraindicación para usarlos me parecería que los sistemas de referencia entre paréntesis pueden crear la impresión (errónea) de que los artículos de Wikipedia son una especie de ensayos (tendenciosos) en los que se hacen resúmenes para probar un punto. - Francis Schonken ( charla ) 06:22, 30 de agosto de 2020 (UTC)
- Apoyo , porque:
- Menos texto en línea facilita la lectura, menos texto que la mayoría de los lectores omitirán de todos modos, y existimos para el beneficio de los lectores, no de los editores. Somos una enciclopedia general, no una revista académica, deberíamos usar lo que sea más fácil para los lectores en general, no para la academia o los editores. (¿Tenemos alguna métrica sobre cuántas personas leen los detalles de la cita?)
- Tenemos un Manual de estilo por una razón: el estilo uniforme facilita la lectura; si se aplican las mismas convenciones a todos los artículos, es más fácil seguir lo que significan. La coherencia debe aplicarse a todos los aspectos, incluidas las citas tal como aparecen en el cuerpo del texto (independientemente de cómo aparezcan en la sección "Referencias"). Para alguien que no esté familiarizado con las referencias entre paréntesis en línea, simplemente puede ofuscar el significado: ¿el autor del artículo de Wikipedia está tratando de decirme algo con el texto entre paréntesis?
- No permitir las citas entre paréntesis en línea no debería evitar que los nuevos editores agreguen material o disuadirlos de continuar editando, al igual que nuestras otras pautas de MOS evitan que las personas utilicen el uso excesivo de mayúsculas, el "estilo de cita ilógico", etc. Los editores experimentados simplemente siguen y editan el artículo para cumplir con MOS, como lo hacemos para muchos otros problemas de estilo, preferiblemente con un enlace a la guía relevante en el resumen de edición. Wikipedia es un esfuerzo común: está bien que los expertos en la materia agreguen material en el "estilo" incorrecto y que los editores experimentados lo "arreglen".
- Mitch Ames ( charla ) 06:52, 30 de agosto de 2020 (UTC)
- ¡Exactamente! Hice eso muchas veces - "arregló" - y nadie nunca se quejó. - BhagyaMani ( charla ) 07:49, 30 de agosto de 2020 (UTC)
- Apoye cualquier cosa para intentar mantener estilos de citas menos generales. Ciertamente, no armas nucleares a la vista, pero deberíamos intentar reemplazarlas con un estilo más consistente. Best Wishes, Lee Vilenski ( charla • contribuciones ) 07:37, 30 de agosto de 2020 (UTC)
- Soporte según Puzzledvegetable - Amkilpatrick ( charla ) 07:49, 30 de agosto de 2020 (UTC)
- Oponerse a que hay tipos de artículos en los que cada estilo funciona mejor. Citar varias páginas del mismo libro no se puede hacer bien con nuestras referencias más estándar, por ejemplo. Debemos permitir a nuestros editores elegir qué estilo funciona mejor para el tipo de artículo que se está escribiendo. ~~ Alex Noble / 1-2 / TRB 07:59, 30 de agosto de 2020 (UTC)
Citar varias páginas del mismo libro no se puede hacer bien con nuestras referencias más estándar
: {{ Rp }} me funciona. Mitch Ames ( charla ) 08:15, 30 de agosto de 2020 (UTC)- Fantástico. ¿Por qué nunca había visto esto antes? - JohnFromPinckney ( charla ) 09:02, 30 de agosto de 2020 (UTC)
- JohnFromPinckney Bueno, lo usé casi en el momento en que apareció. Ver Holocaust Educational Trust , un artículo que comencé. Pero generalmente encuentro que el formato corto es mejor para manejar diferentes números de página (como está entre paréntesis, por cierto). - NSH001 ( conversación ) 09:26, 30 de agosto de 2020 (UTC)
- Fantástico. ¿Por qué nunca había visto esto antes? - JohnFromPinckney ( charla ) 09:02, 30 de agosto de 2020 (UTC)
- Soporte : las referencias entre paréntesis que flotan libremente, sin un enlace a una referencia o nota al pie completamente citada, dejan el texto abierto a preguntas con respecto a su verificabilidad. Esa es mi principal razón para eliminar ese estilo. DonFB ( charla ) 08:25, 30 de agosto de 2020 (UTC)
- Comentario Pero eso no es de lo que estamos hablando (lo mismo puede suceder en otros estilos también). Y, dicho sea de paso, siempre que exista una plantilla de cita CS1 / 2 de destino válida en la lista de bibliografía al final, mi secuencia de comandos ETVP puede corregirla. - NSH001 ( conversación ) 08:42, 30 de agosto de 2020 (UTC)
- @ CaptainEek : ¿ Se permitiría {{ quote }} si la atribución a la fuente se proporciona con una fecha? Thincat ( charla ) 08:57, 30 de agosto de 2020 (UTC)
- Enérgicamente me opongo. De los muchos, muchos problemas que tiene Wikipedia, la gente que hace referencia a artículos usando un estilo perfectamente aceptable en realidad no es uno de los grandes. Entiendo el deseo de alguna forma de uniformidad y prefiero usar etiquetas de referencia yo mismo, pero esto va en contra de CITEVAR que, para mí, es un gran problema. En última instancia, el uso de referencias entre paréntesis garantiza al menos que las personas aprendan a hacer referencia "correctamente", a diferencia de la dependencia de los asistentes de plantillas de citas, que simplemente garantizan que las mismas personas continúen confundiendo al editor y el trabajo, por ejemplo, y no promueven la idea de que hay son diferentes formas de producir referencias. Como otros, tengo la sensación de que esto también es un movimiento hacia el "único estilo verdadero", que es algo con lo que me sentiría incómodo al tratar, y permite una licencia para que la interpretación de su resultado lleve a la eliminación total de un variedad de estilos de referencia. Por favor, envíeme un ping de alguna manera si hay respuesta a esto, ya que de lo contrario no lo veré. Blue Square Thing ( charla ) 09:38, 30 de agosto de 2020 (UTC)
- Soporte : Si no hubiera una expectativa de que los editores usen el estilo de cita que ya existe en el artículo, y así es como se suele interpretar WP: CITEVAR , el contraargumento de que este estilo no causa daño sería correcto. Pero dado que tenemos esta expectativa, obliga a las personas a familiarizarse con estilos de citas inusuales cada vez que quieran editar artículos usándolos, o bien pasar por el aro o simplemente dar una palmada en su propio estilo preferido. Creo que es razonable discutir e implementar una reducción en los estilos de citas para que la gente solo tenga que aprender un número limitado de ellos. Sí, escribí Lake Ptolomeo entre paréntesis, pero cambiarlos al estilo harv no es un problema. Jo-Jo Eumerus ( charla ) 09:48, 30 de agosto de 2020 (UTC)
- Oponerse porque desalentaría a los nuevos editores con experiencia en campos que usan ese estilo, incluidos algunos campos (como algunas de las humanidades) que probablemente estén subrepresentados entre los editores. Un lector muy casual, que probablemente no leerá más allá del encabezado, podría dejar de leer debido al "desorden" de los paréntesis, pero es dudoso que el estilo de la cita disuada a un lector que lee más allá del encabezado. Tendría sentido desalentar el estilo de cita entre paréntesis en el encabezado, donde las citas a menudo son innecesarias de todos modos. Pero no necesitamos nuevas reglas que puedan limitar aún más nuestro grupo de editores. NightHeron ( charla ) 10:41, 30 de agosto de 2020 (UTC)
- Fuerte oposición . Este sería el extremo delgado de la cuña de imponer plantillas de citas estándar. Puedo ver el problema con la legibilidad, pero la causa real de ese problema no son las citas entre paréntesis. Más bien, es la densidad ridículamente alta de citas exigida por muchos revisores en Wikipedia. La densidad de citas ahora ha ido mucho más allá de todo lo que se encuentra en la erudición. Incluso ha ido mucho más allá de lo que se exige en la política de Wikipedia. Solucione ese problema y el problema de la cita entre paréntesis desaparecerá. Spinning Spark 11:06, 30 de agosto de 2020 (UTC)
- La academia no tiene una política WP: OR , todo lo contrario. Esta es la razón por la que Wikipedia tiene tantas citas, y eso es bueno, no es un problema. - Hebsen ( conversación ) 11:44, 30 de agosto de 2020 (UTC)
- @ Hebsen : Sí, Wikipedia es diferente de Acedemia, pero señale otra enciclopedia que tenga densidades de citas de este orden de magnitud. Brittanica no lo hace, ni ninguna enciclopedia en línea, excepto las clonadas de Wikipedia. Spinning Spark 12:22, 30 de agosto de 2020 (UTC)
- Tu no entiendes. Otras enciclopedias no tienen una política WP: OR ; de hecho no necesitan fuentes, porque hay algunos expertos o una institución detrás de ellos, garantizando su confiabilidad. A diferencia de Wikipedia, que es de colaboración colectiva y, por lo tanto, no es confiable en sí misma (las fuentes hacen que el contenido que respaldan sea confiable). - Hebsen ( charla ) 19:05, 30 de agosto de 2020 (UTC)
- @ Hebsen : Sí, Wikipedia es diferente de Acedemia, pero señale otra enciclopedia que tenga densidades de citas de este orden de magnitud. Brittanica no lo hace, ni ninguna enciclopedia en línea, excepto las clonadas de Wikipedia. Spinning Spark 12:22, 30 de agosto de 2020 (UTC)
- La academia no tiene una política WP: OR , todo lo contrario. Esta es la razón por la que Wikipedia tiene tantas citas, y eso es bueno, no es un problema. - Hebsen ( conversación ) 11:44, 30 de agosto de 2020 (UTC)
- Soporte . No veo ningún problema en disuadir a los editores de evitar un uso mínimo de un estilo que formatee correctamente las notas como notas. Es simplemente mejor para la preponderancia de la base de lectores evitar simplemente dejar que los editores introduzcan más didascalia en línea. Nuestro formato visual de notas ha mejorado sustancialmente con el tiempo, lo que permite a los lectores ver el texto de referencia "Foobar 2020, p. 14" casi en línea con solo hacer algo sin interrupciones con el mouse, por lo que quien esté acostumbrado al formato básicamente puede tener casi el misma experiencia. Al igual que ya no deberíamos usar un trillón de {{cite bar | ... | página = 14 | ...}} , y en su lugar deberíamos usar simplemente {{ efn | Foo | 2020}} , tampoco deberíamos decirle a la gente que use referencias en línea sin procesar. - Joy [chalota] ( charla ) 11:10, 30 de agosto de 2020 (UTC)
- Apoyar la desaprobación . Está bien que los artículos todavía estén allí con citas entre paréntesis, está bien que los artículos se creen con citas entre paréntesis, pero creo que es una buena idea, poco a poco, migrar todos esos artículos a un estilo de cita estándar. Aunque las citas entre paréntesis satisfacer nuestras necesidades de abastecimiento, que, básicamente, tiene que desplazarse hacia abajo, identificar qué citación está vinculada a la referencia (y posiblemente marque la referencia). Con las etiquetas , coloque el cursor sobre el número y obtenga la referencia directamente, generalmente incluyendo un enlace a la fuente real si desea verificar más. Me opondría a enviar mensajes a los editores que siguen creando artículos con citas entre paréntesis porque está desaprobado, me opondría al cambio forzado (y / o bot) de las citas entre paréntesis a otros estilos de citas, me opondría a usar armas nucleares a primera vista. Sin embargo, los artículos no deben cambiarse (volver) hacia el uso de citas entre paréntesis, y debe alentarse el cambio al uso de etiquetas . - Dirk Beetstra T C 11:24, 30 de agosto de 2020 (UTC)
- Apoyo débil . Nom ha dado varias razones por las que deben evitarse las citas entre paréntesis. Agregaría los siguientes dos: (a) Un buen artículo de Wikipedia tiene MUCHAS referencias (cuento 107 en el artículo de ~ 3200 palabras) porque cada afirmación necesita una, por lo que el formato debe ser compacto (un formato no compacto desaliente activamente las citas a menos que sea absolutamente necesario); y (b) El uso de notas a pie de página se ha convertido en el estándar de facto de Wikipedia hasta tal punto que los lectores esperan verlo, por lo que no lo usamos confuso para el lector y más difícil de decodificar. En total, creo que todos los inconvenientes del estilo superan las posibles ventajas que podría tener en artículos o temas específicos. No hay una gran diferencia entre usar referencias entre paréntesis y notas al pie abreviadas .
- Recuerde también que la desaprobación no significa que no esté permitido, sino que es aceptable cambiar a otro estilo de cita. No creo que a los recién llegados les resulte más difícil contribuir, ya que los recién llegados a menudo usan lo que quieran, por ejemplo, URL vacías o paréntesis. De hecho, creo que citas parenthethical hacen que sea más difícil para los recién llegados a contribuir a tales artículos, porque el sistema de citación del editor crea automáticamente las notas al pie.
- El apoyo es débil porque no me importa mucho. - Hebsen ( conversación ) 11:44, 30 de agosto de 2020 (UTC)
- Opongo Me deje llevar por argumentos Wugapodes' - los posibles efectos positivos son demasiado pequeños para superar los aspectos negativos potenciales. Por cada ejemplo de atrocidad entre paréntesis, como actuario (que, por cierto, podría y debería cambiarse según las pautas ya existentes ), existe una implementación contrastantemente inofensiva, como el problema de la caída del gato . - Tera tix ₵ 12:39, 30 de agosto de 2020 (UTC)
- Oponerse : aunque no utilizo citas entre paréntesis y prefiero el método de cita que se usa más comúnmente en Wikipedia, el estilo entre paréntesis está lejos de ser inusual en libros y fuentes en línea, y creo que los editores deberían tener la libertad de usarlo si es uno de ellos. a gusto con. Tim riley talk 12:47, 30 de agosto de 2020 (UTC)
- Apoyo. Escribimos para nuestros lectores, no para nosotros. Y nuestros lectores aprecian la estandarización, la legibilidad y la usabilidad, todo lo cual apunta hacia la desaprobación de las citas en línea. Sandstein 12:57, 30 de agosto de 2020 (UTC)
- Oponerse: si se planteara un argumento de IDONTLIKEIT tan endeble en una discusión de eliminación, las burlas serían fuertes. A mí mismo no me entusiasman las citas entre paréntesis, pero a pesar de vox populi , hay muchos lectores y editores que no son de Village Pump que las usan, y no he escuchado una razón para prohibirlas ("desaprobar", en este contexto, es redacción de comadreja) que es más problema de lo que vale la pena. A pesar de todo el culto a la "estandarización" que se lleva a cabo aquí, cualquier lector que huya horrorizado al ver un estilo de cita que no sea de su preferencia es un tonto. Ravenswing 13:26, 30 de agosto de 2020 (UTC)
- Apoye la preferencia MOS por las notas al pie. Ningún editor debe convertir las notas al pie de página en citas entre paréntesis en línea, y se debe permitir a los editores reemplazar las citas en línea con notas a pie de página. pburka ( charla ) 13:38, 30 de agosto de 2020 (UTC)
- Soporte Es preferible un estilo de cita más estandarizado, y un lector casual puede confundirse con las citas entre paréntesis. Normalmente veo citas entre paréntesis en artículos de revistas, tesis y publicaciones académicas destinadas a compañeros académicos, y son útiles para identificar fácilmente a los autores a quienes normalmente reconocerían, o querrían reconocer, y dónde quién dice qué es importante. Esto no es así para Wikipedia, donde los lectores ocasionales no sabrían ni les importaría quién escribió la fuente de referencia. Tener citas entre paréntesis simplemente abarrota el artículo sin impartir información útil para un lector casual. Hzh ( charla ) 13:45, 30 de agosto de 2020 (UTC)
- Apoyo Hacen que los artículos sean mucho más difíciles de leer. ~ mitch ~ ( hablar )
- Soporte porque hacen que los artículos sean difíciles de leer, y los artículos deben escribirse pensando en los lectores. No me convence el argumento de que esto disuadirá a los nuevos editores de contribuir, porque realmente ¿qué tan difícil es poner alrededor de una cita? ¡Está justo debajo del cuadro de edición! Richard75 ( charla ) 14:46, 30 de agosto de 2020 (UTC)
- Soporte . Este no es un problema importante para mí, pero encuentro que cuando me encuentro con un artículo poco común que está formateado de esa manera, me parece tan de los ochenta. Citevar no es un fin en sí mismo, y aunque estoy de acuerdo con otros editores en que lo que más importa es tener fuentes en cualquier formato, también creo que sería muy positivo avanzar en esta dirección. Veo "desaprobación" como algo que debería considerarse aquí como una desaprobación suave , de modo que, si un editor desea revisar el estilo de la cita, eso debería considerarse aceptable, pero aún sujeto a discusión si alguien más se opone. Si hay consenso en una página determinada para seguir con el estilo entre paréntesis, también está bien. - Tryptofish ( charla ) 14:52, 30 de agosto de 2020 (UTC)
- Apoyo : deshacerse de la abominación es un deber para todos. (Y whaatever que digan, ritmo , pero actuario es literalmente una lección.) - S erial 15:51 30 de Agosto de 2020 (UTC)
- Soporte Es un desorden y dificulta la lectura de artículos ( Actuary es deslumbrante). Como Richard75, no compro los argumentos de que esto disuadirá a los nuevos usuarios. ¿Deberíamos abolir MOS: DATE porque los nuevos usuarios escriben regularmente fechas como "24 de abril" y no les gusta que las corrijan? Tampoco veo cómo esto es 'el borde delgado de la cuña' con respecto a WP: CITEVAR . No soporto {{ cite }} y sus variantes y nunca las uso, pero no veo cómo esto conducirá a su imposición. Número 5 7 15:57, 30 de agosto de 2020 (UTC)
- Oponerse . Una prohibición total (asumiendo que eso es lo que se pretende que signifique "desaprobar") excluiría ambos usos entre paréntesis incluso cuando son realmente parte de la información textual. Ejemplo:
- Después de que dos importantes investigadores estadounidenses afirmaron haber encontrado de forma independiente que el agua en realidad no está húmeda (Jones 1996, García 1997), varios canadienses pronto respondieron [de múltiples fuentes] ... Pérouse (1998) fue especialmente vociferante ...
- Ban, no. Como suele ser el caso, ese absoluto podría, y casi con certeza lo haría, ser contraproducente, excluyendo casos útiles, dando como resultado un texto menos informativo que el uso excesivo de listas de aficionados es molesto. El compromiso perenne de Wikipedia: es cierto que el texto debería ser accesible para el tío Everett y la tía Gladys; También es cierto que esto no es la casa de juegos de Pee-wee, sino una enciclopedia. Descalzo por las chollas ( charla ) 16:22, 30 de agosto de 2020 (UTC)
- Soporte En general, tener un estilo de formato consistente mejora la experiencia, tanto del lado de los editores como de los lectores. Wikipedia no debe esperar que las personas aprendan varios métodos de citas diferentes. PieThrowerChamp ( charla ) 16:28, 30 de agosto de 2020 (UTC)
- Soporte según el ejemplo de Actuary , que es visualmente desordenado y desorientador. Creo que la mayoría de los lectores están acostumbrados a las citas numeradas que se utilizan en la gran mayoría de los artículos de Wikipedia. - Granger ( charla · contribuciones ) 16:35, 30 de agosto de 2020 (UTC)
- Fuerte apoyo . La verbosidad es horrenda. El texto del artículo debe estar lo más comprimido posible. Untitled50reg ( charla ) 16:43, 30 de agosto de 2020 (UTC)
- Apoye esto en 2020, tenemos una gran cantidad de herramientas disponibles para nosotros, y este es un ejemplo más de la ineptitud de Wikipedia para adaptarse a los estándares web modernos. Los ejemplos dados de citas entre paréntesis son atroces. ɱ (charla) 16:47, 30 de agosto de 2020 (UTC)
- Soporte El hecho de que toleramos una diversidad de estilos de citas es producto de una anomalía histórica. Siempre que sea posible, debemos trabajar para simplificar los estilos de citas. Este no es especialmente común y no es propicio para acceder rápidamente a la información de un artículo. Ergo Sum 17:05, 30 de agosto de 2020 (UTC)
- Soporte White Whirlwind 18:51, 30 de agosto de 2020 (UTC)
- Oposición leve . Como dijo DGG , lo importante es que se citen los artículos y sus afirmaciones individuales. Airbornemihir ( conversación ) 20:48, 30 de agosto de 2020 (UTC)
- Oponerse Las citas entre paréntesis son un formato conveniente y ampliamente utilizado. La Enciclopedia de Filosofía de Stanford en línea tiene citas en línea (año del autor, página) en el texto principal sin ningún problema aparente de legibilidad. WP de Wikipedia : CITEVAR es una característica indispensable contra la guerra de edición, no un error. Nadie argumentaría a favor de desacreditar a WP: ERA debido a su opinión idiosincrásica de que BCE / CE está más "desordenado" que BC / AD. Keahapana ( charla ) 22:22, 30 de agosto de 2020 (UTC)
- Soporte Si bien estoy totalmente de acuerdo en que lo que realmente importa es que hay citas y que esta información se puede mostrar de muchas formas diferentes, incluidas las citas entre paréntesis, hay un valor significativo en la estandarización y varias desventajas con este formato específico. Por lo tanto, creo que debería haber una preferencia en contra de este formato de cita específico, pero debería considerarse mucho mejor que ninguna cita. - Trialpears ( charla ) 22:41, 30 de agosto de 2020 (UTC)
- Oponerse : "Una consistencia tonta es el duende de las mentes pequeñas". Gog the Mild ( charla ) 22:59, 30 de agosto de 2020 (UTC)
Oponerse, principalmente por la mala formulación de la propuesta, como apunta David Eppstein. No puedo decir completamente qué se propone que se desaproveche o no. Me opongo firmemente a la desaprobación de cualquier referencia entre paréntesis del tipo vinculado o "en el que se puede hacer clic" , como mi plantilla favorita : Harvp . Yo apoyo desaprobación de los no seleccionables; Si eso es lo que quiso decir (y así parece), asegúrese de escribir una propuesta que lo resuma y lo haga más claro. Sin embargo, gracias por tomar la iniciativa. Charla de Walwal20 ▾ contribuciones 23:31, 30 de agosto de 2020 (UTC)- Fuerte oposición . El nominador propone poner cada cita, vinculada o no, dentro de una etiqueta , y creo que sus argumentos para hacerlo no son lo suficientemente convincentes. Citas en línea de tipo Mackey & Glass (1998) son de gran utilidad cuando lo que se dice se dice claramente es un resultado importante logrado por estos autores. Creo que colocarlo en una etiqueta de referencia disminuiría enormemente la importancia de los autores, y puedo ver que esto es indebido en muchos contextos. Walwal20 talk ▾ contribuciones 00:01, 31 de agosto de 2020 (UTC)
- Apoye la noción formal de preferencia de citas, opónganse a prohibir los paréntesis. Mirando algunos de los artículos entre paréntesis, puedo ver por qué a algunas personas les gustaría usarlos. Sin embargo, creo que debería desalentarse por las muchas otras razones de esta discusión. Python integral, haga clic aquí para discutir conmigo 23:52, 30 de agosto de 2020 (UTC)
- Apoye desalentándolo o rechazándolo excepto en circunstancias específicas. Leo actuario y estoy de acuerdo en que realmente satura el texto, daña la estética y parece inconsistente con el resto de Wikipedia. Además, desaconseja agregar citas más específicas, ya que las adicionales empeorarán el desorden. Pensé en limpiarlo, pero me preocupaba que fuera controvertido porque se supone que no se debe cambiar un estilo existente sin un consenso / una buena razón. HaEr48 ( charla ) 00:21, 31 de agosto de 2020 (UTC)
- Fuerte apoyo a la eliminación gradual del sistema de citaciones. He leído todos los argumentos opuestos detenidamente y los encuentro poco convincentes. Es una lectura desagradable e introduce un desorden innecesario en los artículos de Wikipedia. El sistema más popular tampoco es tan difícil de descifrar, especialmente dado que existen plantillas para generar citas. Encurtido de colinabo ( charla ) 02:36, 31 de agosto de 2020 (UTC)
- Apoyo a la eliminación progresiva del sistema de citación. Parece solo una excusa académica para llamar la atención. Guerra ( charla ) 02:53, 31 de agosto de 2020 (UTC)
- Oponerse : cuando me he encontrado con citas entre paréntesis, las he considerado candidatas para la conversión; pero no los considero intrínsecamente intrusivos o confusos. Me he encontrado con al menos un editor experimentado que ha expresado su disgusto por las plantillas sfn, que no son la solución más elegante para su propósito y para las que las referencias entre paréntesis parecen un sustituto útil. A eso se suma el hecho de que cuando los artículos tienen muchos cientos (~ 5-700) de plantillas de citas, las plantillas parecen ser la causa de la reproducción excesivamente lenta de dichas páginas en dispositivos con poca potencia (por ejemplo, una netbook). Aunque las páginas con referencias excesivas son las que tienen menos probabilidades de adoptar el estilo entre paréntesis, es otra razón por la que las plantillas de citas actuales no son la respuesta completa a la referencia (esperando el día en que la referencia se haga a través de identificadores de Wikidata que pueden especificar no solo la fuente también el texto de apoyo relevante de la fuente). Dhtwiki ( charla ) 03:57, 31 de agosto de 2020 (UTC)
- Soporte : más consistencia no puede hacer daño. De hecho, no sabía que Wikipedia usaba este método de citas. Anarchyte ( charla • trabajo ) 04:38, 31 de agosto de 2020 (UTC)
- Oponerse : quiero ver la cita sin tener que mover el mouse al número de nota al pie y / o tener que hacer clic en la nota al pie. Sin embargo, la coherencia es importante. Por lo tanto, es mejor elegir solo uno para todo el sitio. (Pero, ya sabes cuál elegiría eso ...) - ishwar (habla) 05:01, 31 de agosto de 2020 (UTC)
- Oponerse La consistencia en la forma es mucho, mucho menos importante que la consistencia en otros estándares, aquellos para investigar y escribir ... y esos requieren investigadores y escritores, que pueden traer consigo sus propias preferencias sobre el estilo. ¿Por qué alienar a las abejas obreras para aplacar a los gnomos de los
zánganos? Qwirkle ( charla ) 05:53, 31 de agosto de 2020 (UTC) - Apoyo al sistema de citas entre paréntesis que se desaprueba. - al-Shimoni ( charla ) 06:32, 31 de agosto de 2020 (UTC)
- Soporte . Estuve un poco indeciso hasta que miré a Actuary , y luego eché un vistazo a algunas de las otras páginas mencionadas anteriormente como ejemplos de por qué deberíamos seguir usando paréntesis en línea ( problema del gato que cae , grupo de monstruos , etc.) selló el trato para me. Entonces. Mucho. Azul. Retswerb ( charla ) 06:34, 31 de agosto de 2020 (UTC)
- Respaldo, pero tenga en cuenta que la desaprobación no es un proceso claro a la vista . Es justo decir que la mayoría de los lectores encuentran el sistema de notas al pie más conveniente, ya que pueden ver la nota al pie directamente sin tener que desplazarse hacia arriba para continuar. Además, como mencionaron otros editores, la gran cantidad de azul (casi como WP: OVERLINKing ) resulta ser un inconveniente. Entonces, a largo plazo, como Wikipedia está destinada a servir a WP: READERS , el estilo general (notas al pie) es más conveniente en comparación con el estilo WP: HARVARD en línea . Sin embargo, no es gran cosa, y el proceso de cambio tiene WP: NODEADLINES . Eumat114 ( Mensaje ) 06:45, 31 de agosto de 2020 (UTC)
- Soporte En AFC fomentamos el desuso del sistema entre paréntesis. Despreciarlo hace que ese estímulo sea aún más fácil de dar Fiddle Faddle 07:29, 31 de agosto de 2020 (UTC)
- Soporte Las citas entre paréntesis se ven desordenadas y hacen que los artículos sean menos accesibles y más difíciles de leer. Davidelit (Discusión) 09:10, 31 de agosto de 2020 (UTC)
- Apoye las citas en el texto del artículo "normal" y distraiga del contenido propiamente dicho. Por supuesto, tendría que haber algo de esfuerzo para limpiar lo que hay allí, pero desaprobarlo ayudaría a detener el flujo de nuevos artículos con ese estilo. Juxlos ( charla ) 09:59, 31 de agosto de 2020 (UTC)
- Fuerte apoyo No estoy tan lejos de ser un novato en Wikipedia y encuentro que lo que hace que citar sea un dolor es la desconcertante elección que se ofrece, no la falta de ella; el eterno "sí pero también" en el MOS. Wikipedia necesita un estilo de casa. CITEVAR debería irse. y Sfn. Johannes Schade ( charla ) 11:24, 31 de agosto de 2020 (UTC)
- Me opongo a haber dicho apoyo hasta que el comentario de un partidario me haya dirigido a páginas (como la fonología irlandesa ) donde el formato Nombre (fecha) tiene un hipervínculo a la cita completa. Con esto, un desplazamiento del mouse una vez le permite ver cuál es esa fuente, y las citas posteriores no requieren una segunda verificación porque tiene un nombre / fecha, que es mucho más fácil de recordar que un número de nota al pie. Esta es la razón por la que, en general, las revistas impresas prefieren las citas con nombre sobre las notas al pie / notas al final. (Solo había visto anteriormente citas no vinculadas, que son inferiores a un número con hipervínculo). Uno de los problemas que enfrenta Wikipedia es la calidad variable, incluso dentro de lo que la comunidad dice que pasa como fuentes confiables. Es útil para quienes están más familiarizados con un tema poder ver más rápidamente el nivel de confianza en fuentes mejores o peores. OsFish ( charla ) 14:52, 31 de agosto de 2020 (UTC)
- Fuerte oposición . No creo que tengamos que prohibir cosas como esta para empezar. Todos los fundamentos dados están utilizando efectivamente ejemplos de mala edición, como si esto demostrara que no hay una buena manera de usar tales citas, lo cual es claramente incorrecto. Este tipo de cita puede resultar muy útil en determinadas situaciones. Tener la opción disponible es algo bueno .-- Andrew Lancaster ( charla ) 07:26, 1 de septiembre de 2020 (UTC)
- Soporte , pero solo como estándar para nuevos artículos. Si se hizo referencia a la información entre paréntesis en línea antes, la información no debe eliminarse debido a la ref. forma, pero la ref. debe actualizarse. Paradise Chronicle ( charla ) 20:16, 1 de septiembre de 2020 (UTC)
Descanso arbitrario 3 (citas)
- Oponerse , principalmente por Wugapodes y DGG. Debemos eliminar los obstáculos para que los editores creen contenido. Las notas entre paréntesis siempre se pueden convertir más tarde, pero no es necesario desalentar su uso. Los lectores modernos están acostumbrados a hojear el marcado no crítico. Gleeanon409 ( charla ) 10:40, 31 de agosto de 2020 (UTC)
- Un fuerte apoyo para separar las citas del texto en notas a pie de página es importante para hacer que el texto general sea accesible y utilizable por máquinas para diferentes tareas (es decir, evaluar si una oración necesita una cita). Sadads ( charla ) 12:07, 31 de agosto de 2020 (UTC)
- Es probable que se les pueda enseñar a los bots a leer estas citas o al menos marcar el artículo para una revisión adicional. Gleeanon409 ( charla ) 12:48, 31 de agosto de 2020 (UTC)
- Fuerte apoyo - Me parece que es una forma más amigable para el usuario / lector de citar fuentes. Siento que las referencias al estilo de Harvard pueden parecer demasiado académicas, especialmente si se aplican a fuentes que no son libros, artículos de revistas, etc. Paul W ( charla ) 12:33, 31 de agosto de 2020 (UTC)
- Soporte según los comentarios de Alsee en la discusión principal. - The Grid ( charla ) 12:40, 31 de agosto de 2020 (UTC)
- Soporte : como alguien que ha pasado mucho tiempo patrullando nuevas páginas, nunca he visto el uso de citas entre paréntesis en línea. Sin embargo, he visto muchos ejemplos de notas al pie sin citas en línea. En esas situaciones, la página se puede etiquetar o simplemente se pueden agregar citas inclinadas. Aquí, si alguien alguna vez usara paréntesis en línea, la página podría etiquetarse por tener citas incorrectas, o simplemente podría arreglarse manualmente convirtiéndola en notas al pie. No puedo imaginar cómo superar esto crearía una barrera para los nuevos creadores de contenido. En última instancia, WP tiene un MOS masivo que a menudo se aplica incorrectamente o se ignora. ¿Por qué agregar algo nuevo al MOS dañaría el proyecto? Creo que el usuario medio va a entender qué son las notas al pie. ‡ Єl Cid de Valencia charla 13:02, 31 Agosto 2020 (UTC)
- Fuerte apoyo Creo que eliminar las citas en línea mejora el aspecto de los artículos. También creo que estandariza las referencias y es compatible con KISS. Si alguien quiere ver la cita, simplemente coloque el mouse sobre ella. Creo que la mayoría de los lectores pueden darse cuenta de eso. - Ian Korman ( charla ) 14:06, 31 de agosto de 2020 (UTC)
- Comentario Convino en que el uso de paréntesis en Actuario es excesivo e innecesario. En los primeros tres párrafos, todos pueden incluirse en notas al pie, con poca o ninguna pérdida de información textual.
- ¿Esa licencia prohíbe todas las referencias entre paréntesis, o sería un poco como prohibir el vino en las cenas en todo el país porque un pequeño porcentaje de la población está acostumbrado a beber grandes cantidades de "licor" en cualquier momento? ¿El caso extremo de Actuario justifica la prohibición de todos los paréntesis?
- Punto: Lo mejor es realizar la cirugía con un bisturí en lugar de una motosierra. Hay una distinción crucial entre las fuentes de fondo, correctamente anotadas al pie de página, y las referencias que, sí, podrían incluirse en una nota al pie de página, pero que no son solo referencias, sino partes genuinamente informativas del texto, como al relatar la conocida guerra instigada por Smith en su publicación histórica - Smith (1999) provocó una reevaluación básica ... Descalzo a través de las chollas ( charla ) 14:31, 31 de agosto de 2020 (UTC)
- Soporte: las citas entre paréntesis en línea crean mucha confusión y los wikilinks cercanos empeoran las cosas .-- Deepak G Goswami ( charla ) 14:53, 31 de agosto de 2020 (UTC)
- Fuerte oposición : una forma de convertir un no problema en un problema. Solo por el bien de "ILIKEITHISWAY", los editores con experiencia en ese estilo de citas podrían ser alejados de Wikipedia. También en cuadros de citas, notas informativas, metacontexto y otros contextos específicos, las referencias entre paréntesis en línea son posiblemente una mejor opción, de todos modos. ¿Recomendación de no convertir los párrafos en un bosque de apellidos y fechas? Está bien. ¿Prohibición total independientemente del contexto? De ninguna manera --Asqueladd ( charla ) 15:06, 31 de agosto de 2020 (UTC)
Fuerteoposición: lascitas entre paréntesis en línea son particularmente útiles cuando existe la necesidad de hacer referencia a varias páginas separadas de la misma fuente. Que suele ser el caso cuando se trata de artículos de temas antiguos. El uso de citas entre paréntesis resulta en menos desorden en esos casos porque es más fácil señalar páginas específicas. Por ejemplo, "John Doe 1990, p. 3" y "John Doe 1990, pp. 33-35" como citas en línea separadas son más específicas para el material que se obtiene que el otro método en el que sería "... págs. 3–35 ... "o una repetición de toda la plantilla de referencia y la fuente.David Eppstein enumera muchos puntos válidos y sería netamente negativo desalentar activamente un formato de referencia en particular, especialmente cuando ese formato es ampliamente aceptado en las publicaciones y tiene usos únicos. - La silla más cómoda 15:20, 31 de agosto de 2020 (UTC)
- Mi culpa al malinterpretar exactamente lo que se había propuesto. Todavía reafirmaría mi oposición . Desalentar un estilo de referencia que sea aceptado y empleado en ciertas áreas puede desanimar a los nuevos editores de esas áreas de contribuir. Como otros han señalado, su uso es poco común, y si genera demasiado desorden en un artículo, se puede convertir fácilmente a otros formatos de referencia. No veo ningún beneficio en una prohibición total. No es un problema. - The Most Comfortable Chair 06:56, 1 de septiembre de 2020 (UTC)
- {{ sfn }} y {{ r }} pueden usarse para hacer referencia a varias páginas separadas de la misma fuente sin usar citas entre paréntesis. - Ahecht (
PÁGINA DE HABLAR) 20:53, 31 de agosto de 2020 (UTC)
- {{ sfn }} y {{ r }} pueden usarse para hacer referencia a varias páginas separadas de la misma fuente sin usar citas entre paréntesis. - Ahecht (
- Aunque apoyo firmemente los cambios en las políticas y prácticas que hacen más fácil la edición sin comprometer la calidad y facilidad de mantenimiento, me opongo a esta propuesta específica porque está tan mal escrito que, sinceramente, no entiendo lo que se propone exactamente. (Eso es bastante decepcionante en un RfC que se anuncia a todos los editores que han iniciado sesión). Además, no parece que el Editor visual actualmente admita agregar y editar citas de una manera que también facilite los artículos para los editores que no usan ese editor. . Eso, por supuesto, también tendría que respaldar las citas que apuntan a partes específicas de un documento (página, sección, etc.). Cuando llegue a ese estado, deberíamos revisar este tipo de propuesta. ElKevbo ( charla ) 15:27, 31 de agosto de 2020 (UTC)
- Fuerte oposición según DGG, David Eppstein et.al. Como estudiante de humanidades, el sistema de Harvard se me inculcó cuando comencé en la universidad hace muchas décadas. Dejar de lado cualquier sistema de referencia adecuado ampliamente utilizado es una forma segura de desanimar a los novatos que se sienten cómodos usando tales referencias (académicos especializados en la materia, por ejemplo, los nuevos editores más buscados que necesitamos). Esta propuesta no solo es una solución en busca de un problema, sino que de hecho exacerbará el mismo problema que pretende abordar. Roger (Dodger67) ( charla ) 16:34, 31 de agosto de 2020 (UTC)
- Soporte Al principio, cuando pasamos de solo pedir que los artículos terminen con una lista de referencias a requerir citas en línea, el objetivo era fomentar lo último para que no se exigiera un estilo de cita único.
Ese tiempo ya pasó hace mucho tiempo. Nuestra tecnología ha mejorado, por ejemplo. El uso de paréntesis en línea me parece extraño y anticuado, y estoy seguro de que a muchos otros editores. Quizás todavía hay algunos artículos en alguna parte que usan {{ ref }}, el primer sistema de citas que recuerdo haber usado. Al principio me resistí al cambio a {{ cite }} y {{ reflist }}, ya que las últimas notas en columnas, sin importar cuán pocas fueran, lo cual me pareció una tontería en un artículo con solo dos o tres fuentes, pero ese problema ha ahora ha sido corregido durante mucho tiempo. Y gestiona la numeración de notas automáticamente. Los paréntesis en línea aún requieren una gestión de referencias manual y práctica.
Además, la comunidad ha votado con sus teclados. {{ Cite }} es claramente el ganador.
También nos estamos moviendo, cada vez más cada año, a una era en la que la estructuración de datos permitida por Wikidata (algo que era solo un sueño inactivo en 2008 para la mayoría de la comunidad) facilitará la traducción e importación de referencias en todo Wikimedia. proyectos. Esto no puede funcionar con paréntesis en línea.
Y, por último, creo que el estilo entre paréntesis en línea es incorrecto para una enciclopedia, cualquier enciclopedia. Es más apropiado para el tipo de revistas académicas donde la mayoría de los lectores son aquellos que se mantienen al día con el campo en cuestión y se puede esperar razonablemente que conozcan el trabajo citado solo por el autor y el año. Escribimos Wikipedia para mucha más gente que eso.
Escribir referencias de esa manera, también creo, en realidad fomenta ligeramente la inserción de investigación original debido a estas asociaciones y connotaciones académicas.
Es hora, de hecho, ha pasado mucho tiempo desde hace mucho tiempo, que desaprovechemos este estilo para los nuevos artículos y fomentemos la conversión de aquellos artículos que todavía lo usan a referencias de Harvard, que es más propicio para la forma en que hacemos las cosas ahora. Daniel Case ( charla ) 17:03, 31 de agosto de 2020 (UTC)
- Fuerte apoyo: esta propuesta hará que los artículos sean mucho más fáciles de leer y retendrán toda la información relevante. GrammarDamner ¿cómo van las cosas? 17:17, 31 de agosto de 2020 (UTC)
- Fuerte apoyo: muchos de los opositores anteriores no están tomando en cuenta que solo estamos hablando de citas entre paréntesis en línea , no de cualquier tipo de cita entre paréntesis. Muchos otros piensan que por alguna razón trataríamos a un novato que los usa como un vándalo o revertiríamos sistemáticamente sus ediciones si se implementara este cambio, cuando eso está lejos de lo que se está proponiendo. De la misma manera que algunos usuarios simplemente colocan el enlace entre las etiquetas ref y luego otro usuario entra y usa una plantilla de cita adecuada, algún otro usuario vendrá después y cambiará el paréntesis en línea a {{ sfn }} o algo de el tipo. Cualquier novato que use en línea tendrá la libertad de hacerlo, simplemente no podrá mantener un artículo de esa manera solo porque le guste . El Millo ( charla ) 17:29, 31 de agosto de 2020 (UTC)
- Pero las referencias entre paréntesis están, por definición, en línea (entre paréntesis, dentro del texto), ¿no es así? Por supuesto, no puedo hablar por los demás, pero la preocupación por los novatos es para aquellos que buscan las páginas de ayuda sobre referencias y descubren que el estilo que saben usar no pueden usar aquí, pueden desanime contribuir. Y esto no es completamente análogo a cómo manejamos las URL desnudas: la mayoría de los usos de las referencias entre paréntesis son elecciones cuidadosas y consideradas, y los editores que han tomado esas decisiones y luego se han tomado la molestia de implementarlas probablemente no estarán felices si otros vienen y revierten. ellos "porque así es". - Uanfala (conversación) 17:52, 31 de agosto de 2020 (UTC)
- Se desprende del comentario no muy anterior de Fiddle que AFC ya les está negando a sus víctimas la libertad de hacerlo , hasta ahora sin la más mínima autoridad de la comunidad. La propuesta es tan vaga que de lo que estamos hablando es muy poco claro, como se evidencia en una alta proporción de los comentarios anteriores. Estás haciendo un conjunto de suposiciones; otros tienen el mismo derecho a hacer unos completamente diferentes a los que se proponen. Johnbod ( charla ) 17:55, 31 de agosto de 2020 (UTC)
- Muchos opositores citan la referencia a diferentes páginas del mismo libro como argumento, cuando eso se puede hacer perfectamente con {{ sfn }}, por lo que si bien las citas técnicamente entre paréntesis están en línea por definición, el mismo estilo de citas se puede incluir dentro de etiquetas ref y el el problema está resuelto. A eso me refería. Supongo que estaría más a favor de decir que es el estilo preferido sin desaprobarlo por completo, pero aún así apoyaré esta propuesta. Por "estilo preferido", me refiero a que no sería necesario llegar a un consenso para cambiar un artículo de referencias en línea a estilo reftag, porque ya habría un consenso para este último en la comunidad en general. El Millo ( charla ) 18:31, 31 de agosto de 2020 (UTC)
- ¿Qué? De ninguna manera el comentario de Fiddle equivale a negarle algo a sus víctimas. Esta es una hipérbole ridícula. Además, si el 99% de los comentaristas entiende la propuesta claramente y el uno por ciento no, el problema probablemente esté en el 1%. AIR corn (charla) 22:11, 31 de agosto de 2020 (UTC)
- Dice “En AFC fomentamos el desuso del sistema entre paréntesis. Depreciarlo hace que ese estímulo sea aún más fácil de dar Fiddle Faddle "-" alentar el desuso "seguramente significa no permitir que los artículos se aprueben si usan referencias entre paréntesis. ¿Qué más podría significar? De los votos que entran en detalles se desprende claramente que los votantes Ambas partes tienen ideas muy divergentes sobre lo que significa o debería significar la propuesta. Johnbod ( charla ) 13:43, 1 de septiembre de 2020 (UTC)
- Esa es su propia interpretación de su comentario, en mi opinión incorrecta.
alentar el desuso
puede significar tanto decirle a alguien que considere aprender a usar referencias de etiquetas de referencia en contribuciones futuras, al igual que alguien podría decirle a otra persona que considere usar una plantilla de {{ cite web }} en lugar de simplemente poner un vínculo entre etiquetas ref. Preguntémosles. Violín , ¿te importaría aclarar? El Millo ( charla ) 18:18, 1 de septiembre de 2020 (UTC)- Facu-el Millo , Precisamente como se dijo. Fomentamos el desuso. No es un factor de activación Fiddle Faddle 19:33, 1 de septiembre de 2020 (UTC)
- Esa es su propia interpretación de su comentario, en mi opinión incorrecta.
- Dice “En AFC fomentamos el desuso del sistema entre paréntesis. Depreciarlo hace que ese estímulo sea aún más fácil de dar Fiddle Faddle "-" alentar el desuso "seguramente significa no permitir que los artículos se aprueben si usan referencias entre paréntesis. ¿Qué más podría significar? De los votos que entran en detalles se desprende claramente que los votantes Ambas partes tienen ideas muy divergentes sobre lo que significa o debería significar la propuesta. Johnbod ( charla ) 13:43, 1 de septiembre de 2020 (UTC)
- ¿Qué? De ninguna manera el comentario de Fiddle equivale a negarle algo a sus víctimas. Esta es una hipérbole ridícula. Además, si el 99% de los comentaristas entiende la propuesta claramente y el uno por ciento no, el problema probablemente esté en el 1%. AIR corn (charla) 22:11, 31 de agosto de 2020 (UTC)
- No me siento lo suficientemente fuerte como para ser atrevido, pero creo que estoy principalmente con xaosflux. No prohíba ni proscriba los paréntesis en línea, pero cambie CITEVAR para permitir cualquier conversión de buena fe al estilo de cita estándar (es decir, sin tener que buscar un consenso por separado). (No planeo ver esta discusión, así que envíeme un ping si es necesario). - BDD ( charla ) 18:16, 31 de agosto de 2020 (UTC)
- Soporte para el primer y segundo tipo de desaprobación de AntiCompositeNumber: declarar formalmente que las citas de notas finales de hipertexto son el estilo de cita preferido de Wikipedia y preautorizar la conversión no controvertida de citas entre paréntesis en línea al estilo de nota final más fácil de usar. Si un editor nuevo (o cualquier editor) prefiere usar el estilo entre paréntesis, entonces debería tener la libertad de hacerlo, pero cualquier otro editor que quiera hacer que el artículo sea más fácil de leer debería tener la libertad de saltar y cambiar las citas a El estilo preferido de Wikipedia. - Bryan Rutherford ( charla ) 20:02, 31 de agosto de 2020 (UTC)
- Soporte Este tipo de citas se está volviendo menos común con el tiempo. En este punto, todo lo que hacen es crear un inconveniente para los lectores, porque hacen que el artículo se vea desordenado. Es hora de seguir adelante. Scorpions13256 ( charla ) 20:06, 31 de agosto de 2020 (UTC)
- Fuerte soporte Estos tipos de referencias distraen debido a lo poco comunes que son en Wikipedia, y es mucho más limpio y más legible que se deleguen en una etiqueta de referencia. Wikipedia está en línea y la gente debería hacer uso de las herramientas que ofrece. Cada vez que veo personas que usan * † ‡, etc. para las notas al pie, siempre las cambio a EFN porque se deben usar hipervínculos cuando sea posible. La misma idea va con las citas entre paréntesis en línea, es mucho más claro sin las citas. Nixinova T C 20:25, 31 de agosto de 2020 (UTC)
- Soporte Wikipedia es hipertexto, no hay ninguna razón por la que debamos ceñirnos a las convenciones basadas en publicaciones impresas que requieren abarrotar artículos con nombres de citas cuando la cita completa podría estar a un clic de distancia. Hay muchas formas de solucionar el problema de "múltiples citas a diferentes secciones de la misma fuente", incluido el uso de notas al pie abreviadas (a través de {{ sfn }}) o el uso de {{ r }} para agregar un nombre de página o sección en superíndice. También está el próximo meta: WMDE Technical Wishes / Book referencing , que le permite hacer algo como
Page 25
. - Ahecht (
PÁGINA DE HABLAR) 20:53, 31 de agosto de 2020 (UTC) - Soporte . Las referencias entre paréntesis son engorrosas y distraen de la perspectiva del lector promedio. Wikipedia no es papel y deberíamos aprovechar al máximo sus capacidades para las citas en línea. - Sable232 ( charla ) 22:05, 31 de agosto de 2020 (UTC)
- Los artículos de apoyo están escritos para lectores, no para autores. Esta no es una prensa universitaria diseñada para élites. Es para todos. Además, existe una cosa llamada hipertexto. - Rob ( charla ) 22:13, 31 de agosto de 2020 (UTC)
- Oponerse -Lo más importante es conseguir artículos con buenas fuentes. Obligar a los editores a evitar el estilo entre paréntesis, particularmente aquellos con experiencia en algunos archivos y que están acostumbrados a ese estilo, solo aumenta el desánimo del que se quejan las personas que intentan editar aquí. ¿Alguien tiene alguna evidencia de que este estilo de cita sea un problema real para los lectores reales? Cuando le digo a la gente que edito mucho en Wikipedia, escucho todo tipo de historias. Nunca escuché a nadie mencionar las referencias entre paréntesis como un problema, pero recibo quejas todo el tiempo sobre lo burocráticos que somos .-- agr ( hablar ) 23:17, 31 de agosto de 2020 (UTC)
- Probablemente se deba a que los artículos con este tipo de estilo de cita son muy raros. Por mi parte, nunca me he encontrado con uno solo, sin contar los que se han puesto como ejemplos en este RfC, por supuesto. El Millo ( charla ) 02:12, 1 de septiembre de 2020 (UTC)
- Si son raros, ¿por qué hacer un cambio de política polémico? Obtenga consenso local y vaya a cambiar los pocos que tienen alta visibilidad .-- agr ( charla ) 12:28, 3 de septiembre de 2020 (UTC)
- En mi opinión, este cambio de política haría oficial y aclararía la preferencia por las etiquetas de referencia sobre la notación entre paréntesis. No prohíbe los paréntesis, pero deja en claro para un editor que intenta escribir según los estándares de Wikipedia cuál es el estilo preferido. Carter ( charla ) 13:01, 3 de septiembre de 2020 (UTC)
- Si son raros, ¿por qué hacer un cambio de política polémico? Obtenga consenso local y vaya a cambiar los pocos que tienen alta visibilidad .-- agr ( charla ) 12:28, 3 de septiembre de 2020 (UTC)
- Probablemente se deba a que los artículos con este tipo de estilo de cita son muy raros. Por mi parte, nunca me he encontrado con uno solo, sin contar los que se han puesto como ejemplos en este RfC, por supuesto. El Millo ( charla ) 02:12, 1 de septiembre de 2020 (UTC)
- Fuerte apoyo tanto para desalentar el nuevo uso como para reemplazarlos a menos que haya un consenso específico en contra de hacerlo. Nick Number ( conversación ) 23:58, 31 de agosto de 2020 (UTC)
- Soporte . El hipertexto permite saltar fácilmente a las fuentes o aparecer cuando se pasa el cursor sobre ellas. La depreciación de las citas entre paréntesis no prohíbe su uso, y hay algunos casos en los que puede tener sentido, pero las preferidas deberían ser reftags. Carter ( charla ) 00:17, 1 de septiembre de 2020 (UTC)
- Soporte Con la condición de que se alcance el consenso de la página de discusión antes de cambiar retroactivamente cualquier artículo existente a un formato diferente. Tonystewart14 ( charla ) 00:31, 1 de septiembre de 2020 (UTC)
- Bajo esta condición, ¿en qué se diferenciaría esta propuesta de las directrices ya existentes ? - Tera tix ₵ 03:18, 1 de septiembre de 2020 (UTC)
- Soporte Según los extensos argumentos anteriores. Loopy30 ( charla ) 01:58, 1 de septiembre de 2020 (UTC)
- Soporte . Tenía dos opiniones sobre esto, ya que en toda mi carrera, escribiendo con dos antecedentes académicos y uno profesional, siempre he usado notas a pie de página, no citas entre paréntesis, y tenía miedo de dejar que mi experiencia personal me sesgara. Luego intenté leer el artículo del Actuario. Si ese es un uso válido de citas en línea entre paréntesis, y parece que lo es, entonces creo que debe eliminarse lo más rápido posible. Ese estilo hace que sea extremadamente difícil leer el artículo. Creo que las notas a pie de página se entienden más comúnmente y son más accesibles. Mi opción sería una fuerte preferencia por las notas a pie de página, con paréntesis en desuso (al igual que las URL desnudas). Mr Serjeant Buzfuz ( charla ) 03:53, 1 de septiembre de 2020 (UTC)
- Soporte para futuros artículos. Simplifica la lectura y da más coherencia a toda la Wikipedia. Los artículos existentes que utilizan el formato se pueden convertir con el tiempo sin prisas. - Ita140188 ( charla ) 05:26, 1 de septiembre de 2020 (UTC)
- Soporte . Especialmente para una audiencia general, es importante minimizar la molestia de las citas. Basándome en las aclaraciones de la propuesta, estoy bastante satisfecho de que esta es una forma adecuada de abordar un estilo de cita que ya es impopular en Wikipedia y (en mi opinión) resta valor a la legibilidad. - biggins ( charla ) 07:45, 1 de septiembre de 2020 (UTC)
- Apoyo. Wikipedia sirve al público en general. No es un brazo de la academia y las referencias entre paréntesis son un desastre para leer y editar. Pyxis solitario (yak) . No L Q . 07:50, 1 de septiembre de 2020 (UTC)
- Oponerse según Wugapodes et al. Las desventajas superan la ventaja mínima de una legibilidad ligeramente más fácil. Jakob.scholbach ( charla ) 08:01, 1 de septiembre de 2020 (UTC)
- Apoyo según los argumentos de otros. Preferiría no repetir. Flyer22 Frozen ( charla ) 08:37, 1 de septiembre de 2020 (UTC)
- Dada la gran variedad de lo que la gente piensa que significa esta propuesta, sería útil para el vendedor si pudiera especificar al menos lo que apoya, incluso si omite el motivo . Johnbod ( charla ) 13:36, 1 de septiembre de 2020 (UTC)
- Apoyo : otros han vuelto a decir lo que yo habría dicho aquí. stwalkerster ( charla ) 10:40, 1 de septiembre de 2020 (UTC)
- Soporte , siempre que no golpeemos a los novatos con él. Las citas entre paréntesis son un vestigio de los días del lápiz y el papel, realmente no hay una ventaja sobre las plantillas de notas al pie. Si la gente quiere, simplemente puede desplazarse o hacer clic en los números azules, no es una gran molestia y vale la pena el intercambio para facilitar la lectura. Ahora que tenemos la tecnología digital para hacer que las citas sean menos intrusivas, abracémosla en lugar de aferrarnos al pasado. - A Morozov 〈talk〉 10:56, 1 de septiembre de 2020 (UTC)
- Soporte Otros editores se han extendido sobre esto con mucho más detalle, pero creo que las notas al pie son mucho más consistentes, legibles y fáciles de usar. No creo que esto vaya a dificultar la contribución a Wikipedia. Si un nuevo editor comienza a editar con citas entre paréntesis, entonces otro editor simplemente vendrá y las editará, muy parecido a cómo funcionan las cosas en el resto de la enciclopedia. S am W alton ( charla ) 10:58, 1 de septiembre de 2020 (UTC)
- Soporte . La enmienda a la MOS debería dejar en claro que las citas de Harvard siguen siendo bienvenidas (y en muchos casos son las más apropiadas) siempre que estén incluidas en etiquetas de referencia. Si se hace correctamente, el mouse sobre el número de referencia aparecerá
Smith (2008)
con un enlace directo a la publicación específica. - John Maynard Friedman ( charla ) 12:47, 1 de septiembre de 2020 (UTC) - Soporte La legibilidad es la principal preocupación de la wiki. Otros problemas son secundarios. Cabayi ( charla ) 13:19, 1 de septiembre de 2020 (UTC)
- Support Wikipedia no es una revista académica, y los lectores no deben sentirse agobiados por notas a pie de página intrusivas. De hecho, si me saliera con la mía, el modo predeterminado de Wikipedia no mostraría notas al pie en absoluto; haría clic en un botón para activarlos, si está realmente interesado en las fuentes. - Kent G. Budge ( charla ) 13:53, 1 de septiembre de 2020 (UTC)
- Kent G. Budge , En general, estoy de acuerdo en que deberíamos permitir que los lectores consuman nuestro contenido de la forma que les resulte más útil. Y, de hecho, nuestro marcado HTML está lo suficientemente estructurado como para ocultar las referencias probablemente una línea de CSS agregado.
- Pero voy a rechazar la idea de que ocultar las referencias debería ser la opción predeterminada. Es importante que dejemos en claro a nuestros lectores que solo somos una fuente de WP: TERTIARY . Mostrar las referencias por defecto enmarca cómo esperamos que los lectores traten lo que decimos, es decir, con una dosis adecuada de escepticismo y la necesidad de verificar todo. Si ocultamos las referencias de forma predeterminada, eso alienta a las personas a confiar en nosotros sin verificación. - RoySmith
(charla) 14:26, 1 de septiembre de 2020 (UTC)
- Y, sin embargo, las enciclopedias impresas con las que crecí no tenían notas a pie de página. Simplemente identificarían al colaborador de cada artículo, y había una página de colaboradores separada que enumeraba las credenciales de cada uno.
- Esto no funciona para Wikipedia porque Wikipedia no requiere credenciales de sus autores. En cambio, requiere fuentes confiables de sus autores. Creo que se deduce que las citas son principalmente para autores y editores, no para el público lector. Aunque reconozco que es una obviedad que los investigadores serios no vienen a Wikipedia en busca de información; acuden a él por sus listas de fuentes.
- Pero debo enfatizar, antes de que esto se desvíe, que en realidad no estoy proponiendo desactivar las citas por defecto en el corto plazo. Hice ese comentario para enfatizar que creo que las citas deben ser tan discretas como sea razonablemente posible, para minimizar la carga para los lectores. - Kent G. Budge ( charla ) 14:36, 1 de septiembre de 2020 (UTC)
- Pero voy a rechazar la idea de que ocultar las referencias debería ser la opción predeterminada. Es importante que dejemos en claro a nuestros lectores que solo somos una fuente de WP: TERTIARY . Mostrar las referencias por defecto enmarca cómo esperamos que los lectores traten lo que decimos, es decir, con una dosis adecuada de escepticismo y la necesidad de verificar todo. Si ocultamos las referencias de forma predeterminada, eso alienta a las personas a confiar en nosotros sin verificación. - RoySmith
(charla) 14:26, 1 de septiembre de 2020 (UTC)
- Apoyo Las citas entre paréntesis distraen la fluidez de la lectura del texto. Pone a los lectores la responsabilidad de obtener un texto y hojear las páginas para ver si la referencia incluso respalda la afirmación. Veo estas citas entre paréntesis como simplemente "vagas", y la noción de que podrían arreglarse más tarde ... bueno, sabemos que la realidad rara vez se concreta. - AppleBsTime ( conversación ) 15:20, 1 de septiembre de 2020 (UTC)
- Me opongo a que las explicaciones de CaptainEek sobre la propuesta tienen frases que son vagas (“muchas cosas han cambiado desde entonces” y “nuestro estilo se vuelve más estandarizado y formal”), y me gustaría saber qué significa. La propuesta parece estar resolviendo un problema que CaptainEek sugiere que es un problema pequeño. Respetando lo que se dice en las numerosas oposiciones anteriores: la solución sugerida por CaptainEek reemplazará un pequeño problema con otros pequeños problemas. Un problema de citas más importante y serio es la precisión y la verificabilidad: no ser quisquilloso con el estilo con los editores que pueden ser nuevos, que pueden ser precisos, que pueden ser académicos, a quienes se debe alentar, no desanimar. (Einbildungskraft) ( charla ) 15:29, 1 de septiembre de 2020 (UTC)
- Comentario TL; DR: MOS RfC son una forma válida de establecerse en un estilo interno preferido. No son una forma válida de determinar los hechos de la experiencia del usuario. Cuando el RfC se basa en gran medida en tales hechos (como es el caso aquí), busque los hechos primero.
- Este RfC podría ser una encuesta de opinión válida o una construcción de consenso sobre qué estilo de referencia prefieren los editores de Wikipedia, pero determinar qué prefieren los lectores es una historia diferente. Un RfC sobre estilos de citas está destinado a sufrir un gran sesgo de selección hacia los editores que se preocupan por tales cosas, por lo tanto, que ya tienen una familiaridad mucho mayor con las referencias que el editor promedio y mucho menos el lector.
- Mi comprensión del lector promedio de Wikipedia, basado en las interacciones IRL, es que no se preocupan por las citas y solo las verificarían si una afirmación parece extravagante. Si mi muestra fuera representativa, la mejor solución en términos de legibilidad para la audiencia sería ocultar las referencias a los lectores, o tal vez tener un botón para activarlas o desactivarlas en Google (con la opción predeterminada desactivada), y probablemente dejar que los editores usen lo que quieran en el backstage.
- ¿Mi muestreo / sentimiento es una buena aproximación al lector promedio de Wikipedia? Probablemente no. Pero probablemente tampoco lo sea el de quien escribe
La mayoría de las personas se han encontrado con estilos de citas entre paréntesis en algún momento de sus vidas.
(La mayoría de los académicos , claro, la mayoría de los editores de Wikipedia , tal vez, pero ciertamente no la mayoría de los lectores de Wikipedia , y mucho menos la mayoría de la gente ). Estoy destacando a los Wugapodes aquí porque era fácil extraer una oración para criticar, pero otros argumentos sobre lo que quieren los lectores son dudosos. también. - Por ejemplo, muchos partidarios dicen que las notas al pie de Wikipedia son una buena usabilidad, o al menos una mejor usabilidad que el paréntesis. Así es como yo personalmente me siento, pero ¿es realmente el caso del lector medio? La única evidencia que se ve, que es muy circunstancial, es que pocos sitios web modernos, si es que hay alguno, usan notas al pie de página vinculadas, en particular sitios web de noticias, cuyos ingresos dependen de cuán legibles son (y cuyo lector promedio es probablemente similar al de Wikipedia). Esto sugiere que las notas a pie de página en los sitios web tienen un diseño deficiente por alguna razón. Sin embargo, ¿la razón se aplica a Wikipedia?
- Tigraan Haga clic aquí para contactarme 15:31, 1 de septiembre de 2020 (UTC)
- @ Tigraan : Este no es solo mi sentimiento personal; Existe una gran cantidad de literatura en educación y ciencia de la información sobre cómo enseñar la atribución de fuentes en el texto en los niveles de la escuela primaria y secundaria. Vieyra y Weaver ( 2016 ) brindan una descripción general de esta literatura y señalan que, si bien los estudiantes de la escuela secundaria no son particularmente buenos para crear citas en el texto, al menos son preventivos. Recibieron 198 ensayos de estudiantes entre los grados 6 y 12 y el 32% de esos ensayos contenidos en citas de texto (casi todos tenían páginas de referencia). Esta tasa varió según el nivel de grado, y es mucho más probable que los estudiantes de secundaria proporcionen citas en el texto (alcanzando un máximo en los grados 10 y 11, donde la mayoría contenía citas en el texto; consulte la figura 1). También informan de una encuesta de profesores universitarios en la que preguntaron por las percepciones de los profesores sobre cuánta práctica tenían los estudiantes universitarios de primer año en la escuela secundaria con citas de texto, y de los 23 profesores que encuestaron a todos menos a 3 estudiantes previos que tenían al menos una práctica mínima con cita en el texto. Como punto curricular, la Asociación Estadounidense de Bibliotecarios Escolares y sus miembros han estado trabajando para mejorar la competencia de los estudiantes en las citas, y con solo buscar en Internet los sitios web de bibliotecas de escuelas secundarias se mostrará un número significativo que proporciona información sobre los estilos de citas de MLA y APA (p. Ej., Garfield HS , Ladysmith Library ) a menudo con punteros a Purdue OWL que describe en formatos de citas de texto para esos estilos. Los recursos de preparación de exámenes para los exámenes estandarizados de la escuela secundaria, como los exámenes de Colocación Avanzada, también recomiendan que los estudiantes utilicen algún tipo de atribución en el texto para recibir calificaciones altas (por ejemplo, del Distrito Escolar de Spring Grove ). Si bien mi redacción puede no haber sido la más precisa, no se puede simplemente pasar la literatura sobre la enseñanza en citas de texto a estudiantes de secundaria y preparatoria, lo que sugiere que una proporción considerable de nuestros lectores la ha encontrado . - Wug · a · po · des 21:15, 1 de septiembre de 2020 (UTC)
- "Atribuya sus argumentos a las fuentes" no es lo mismo que "use (autor, año) estilo"; de hecho, el quid de este RfC es el estilo de cita que se debe usar, no renunciar por completo a las citas. De su primera referencia, la tabla 2 parece incluir un ejemplo de referencias numeradas. También dice
alrededor de un tercio de los profesores de ciencias piensan que los estudiantes han tenido al menos una práctica moderada (...) usando un estilo de cita estándar (35%)
; aunque lo que piensa el profesorado es diferente de la realidad, y un "estilo de cita estándar" no lo es necesariamente (autor, año). En cuanto a los últimos argumentos, si los recursos están disponibles en las bibliotecas para estudiantes motivados es irrelevante para la pregunta de si la mayoría de los estudiantes los usarán. - Además, esto nos habla de los estudiantes estadounidenses. Estoy bastante seguro de que las ferias científicas (por ejemplo), citadas en su referencia como un contexto donde se necesita una cita adecuada, no son una cosa en el Reino Unido (ciertamente no lo son en Francia). Wikipedia en inglés no es Wikipedia en EE. UU. (En todo caso, por población, sería Wikipedia en India). Tigraan Haga clic aquí para contactarme 09:01, 2 de septiembre de 2020 (UTC)
- Es obvio que ni siquiera leíste el periódico. La Tabla 2 no se trata de citas en el texto y el artículo dice explícitamente que dos oraciones antes:
La presencia e integridad de las citas en la página de referencia al final del informe se evaluó utilizando la rúbrica en la Tabla 2
(énfasis agregado). Los ejemplos son ejemplos numerados, no ejemplos de notas al pie numeradas. Si estuvieran destinados a ser ejemplos de notas al pie numeradas, no esperaríamos que los autores cambiaran repentinamente de notas al pie numeradas a no numeradas para el nivel 3 a pesar de mantener la misma cita bibliográfica. Si desea la tabla de citas en el texto, debe leer la Tabla 1, que está convenientemente titulada "citas en el texto". Sí, los profesores pueden no ser el grupo de encuesta perfecto, pero ¿qué evidencia ha presentado para respaldar sus afirmaciones de que sus percepciones están desconectadas de la realidad? Dudo que la conexión sea tan tenue como sugiere, dado que las percepciones de los profesores están en consonancia con los otros resultados del artículo, así como con los ejemplos independientes que proporcioné. - También le sugiero que lea las estadísticas de visitas a páginas de Wikimedia por país, lo que contradice sus afirmaciones sobre los lectores. Tuvimos 3 mil millones de páginas vistas de los EE. UU. El mes pasado, que es la pluralidad de nuestras 9 mil millones de páginas vistas. India constituía 700 millones y el Reino Unido 800 millones, por lo que me gustaría tener alguna evidencia de su afirmación de que somos India-Wikipedia, especialmente considerando que menos del 11% de la población de la India habla inglés . Además, el ejemplo de la Biblioteca Ladysmith que proporcioné es de Columbia Británica, Canadá y fue elegido específicamente por su representación de una perspectiva no estadounidense. ¿He realizado una revisión bibliográfica completa y un estudio de los planes de estudios internacionales? No claro que no; Tengo otras cosas que hacer. Si la evidencia que he presentado no le satisface, le sugiero que haga su propia investigación para respaldar su posición en lugar de intentar forzar un argumento desde la ignorancia . Ha hecho dos afirmaciones que se demuestran fácilmente como falsas, por lo que simplemente no confío en su intuición. - Wug · a · po · des 20:30, 2 de septiembre de 2020 (UTC)
- Si la lista de referencias al final de un artículo está numerada, obviamente las marcas de cita en el texto son números en lugar de año del autor. (Tener marcas de citación del año del autor y dar la lista de referencias como una lista numerada por orden de aparición no tendría sentido). Los ejemplos de la tabla están numerados en las dos ubicaciones donde se dan múltiples referencias, pero estoy de acuerdo en que no prueba de manera concluyente que los autores intentaron demostrar un esquema de referencias numeradas.
- Incluso si "el 35% de los profesores piensa que los estudiantes tienen una práctica moderada con una CS estándar" implica que "el 35% de los estudiantes tienen una práctica moderada con una CS estándar", eso a su vez no significa que la mayoría (51%) de los estudiantes hayan practicado un estándar CS, ni que dicho estándar sea (autor, año). Mi comentario sobre las percepciones de los profesores pretendía ser una concesión de que las cosas podrían ser mejores de lo que perciben los profesores (porque los profesores podrían esperar estándares más altos de los estudiantes de lo que sería suficiente).
- En cuanto a las estadísticas de visualización de países, admito que estoy algo sorprendido, pero mi punto principal fue que incluso si las visitas a una página en los EE. UU. Fueran el 90% de todo el tráfico, no justificaría alinear las prácticas de Wikipedia con las prácticas de EE. UU.
- No tengo una posición sobre el RfC precisamente porque no he visto evidencia de que las referencias de las notas al pie sean más o menos fáciles de usar que (autor, año). Si hubiera demostrado que (autor, año) es algo que una gran fracción de los estudiantes de EE. UU. Usa o lee durante la escuela secundaria (o al menos es significativamente más común que las referencias numeradas), no sería una prueba directa (no dice nada sobre el situación fuera de EE. UU., más común ≠ mejor para UX, etc.) pero me habría movido a oponerme porque todos los demás argumentos que he leído aquí son evidencia anecdótica. No creo que sus árbitros demuestren eso, pero al menos lo felicito por tratar de traer los hechos a la mesa. Tigraan Haga clic aquí para contactarme 10:34, 3 de septiembre de 2020 (UTC)
- Es obvio que ni siquiera leíste el periódico. La Tabla 2 no se trata de citas en el texto y el artículo dice explícitamente que dos oraciones antes:
- "Atribuya sus argumentos a las fuentes" no es lo mismo que "use (autor, año) estilo"; de hecho, el quid de este RfC es el estilo de cita que se debe usar, no renunciar por completo a las citas. De su primera referencia, la tabla 2 parece incluir un ejemplo de referencias numeradas. También dice
- @ Tigraan : Este no es solo mi sentimiento personal; Existe una gran cantidad de literatura en educación y ciencia de la información sobre cómo enseñar la atribución de fuentes en el texto en los niveles de la escuela primaria y secundaria. Vieyra y Weaver ( 2016 ) brindan una descripción general de esta literatura y señalan que, si bien los estudiantes de la escuela secundaria no son particularmente buenos para crear citas en el texto, al menos son preventivos. Recibieron 198 ensayos de estudiantes entre los grados 6 y 12 y el 32% de esos ensayos contenidos en citas de texto (casi todos tenían páginas de referencia). Esta tasa varió según el nivel de grado, y es mucho más probable que los estudiantes de secundaria proporcionen citas en el texto (alcanzando un máximo en los grados 10 y 11, donde la mayoría contenía citas en el texto; consulte la figura 1). También informan de una encuesta de profesores universitarios en la que preguntaron por las percepciones de los profesores sobre cuánta práctica tenían los estudiantes universitarios de primer año en la escuela secundaria con citas de texto, y de los 23 profesores que encuestaron a todos menos a 3 estudiantes previos que tenían al menos una práctica mínima con cita en el texto. Como punto curricular, la Asociación Estadounidense de Bibliotecarios Escolares y sus miembros han estado trabajando para mejorar la competencia de los estudiantes en las citas, y con solo buscar en Internet los sitios web de bibliotecas de escuelas secundarias se mostrará un número significativo que proporciona información sobre los estilos de citas de MLA y APA (p. Ej., Garfield HS , Ladysmith Library ) a menudo con punteros a Purdue OWL que describe en formatos de citas de texto para esos estilos. Los recursos de preparación de exámenes para los exámenes estandarizados de la escuela secundaria, como los exámenes de Colocación Avanzada, también recomiendan que los estudiantes utilicen algún tipo de atribución en el texto para recibir calificaciones altas (por ejemplo, del Distrito Escolar de Spring Grove ). Si bien mi redacción puede no haber sido la más precisa, no se puede simplemente pasar la literatura sobre la enseñanza en citas de texto a estudiantes de secundaria y preparatoria, lo que sugiere que una proporción considerable de nuestros lectores la ha encontrado . - Wug · a · po · des 21:15, 1 de septiembre de 2020 (UTC)
- Oppose Wikipeda no 'avanza' al desarrollar un estilo más estandarizado y formal, avanza aumentando su alcance junto con la precisión y verificabilidad de la información contenida en él. Ese fin se basa en alentar a cualquier editor potencial a contribuir, y cualquier cosa que pueda erosionar o desanimar esa contribución, debe ofrecer algo significativo y significativo a cambio. De hecho, esta es una forma muy rara de estilo de cita, pero no es difícil de comprender y con miles de páginas pidiendo referencias a gritos, ¿por qué demonios querríamos erosionar la variedad de formas en que se puede hacer? Si bien entiendo la necesidad de un estilo más unificado, no creo que se justifique la eliminación de esta opción. Mighty Antar ( charla ) 16:04, 1 de septiembre de 2020 (UTC)
- Oponerse . Agregaría la palabra fuerte , pero no creo que influya en el cierre de los administradores, y la fuerza de mi apoyo a WP: CITEVAR es, espero, bastante conocida. En un mundo perfecto, Wikipedia tendría un estilo propio, pero con el bot de citas y sus operadores causando interrupciones continuas, [1] esto está lejos de ser un mundo perfecto, y no deberíamos hacer nada que dé más autoridad a los bots que a los lectores. y nuevos editores. Cada nuevo editor estará familiarizado con un estilo diferente, y muchos editores existentes (de hecho, artículos destacados) utilizan estilos de citas en línea que son comunes a esa área de contenido. En el entorno actual, esta propuesta simplemente conduciría a un mayor control de bots, interrupciones y errores introducidos por los operadores de bots. Me opongo firmemente a cualquier movimiento para quitarle el estilo de las citas a los editores que escriben artículos, e igualmente espero que estos problemas de bots desaparezcan para que algún día podamos trabajar hacia un estilo de casa, sin interrupciones. Sandy Georgia ( Discusión ) 16:16, 1 de septiembre de 2020 (UTC)
- @ SandyGeorgia : Que quede claro que el uso de bots para solucionar esto no es parte de la propuesta, y por lo que he leído, la mayoría de los partidarios aquí se opondrían al uso de bots para esto. El Millo ( charla ) 18:29, 1 de septiembre de 2020 (UTC)
- Y predigo que tan pronto como eliminemos cualquier método de citación manual, veremos a los bots entrar y cometer errores que perjudicarán tanto a los lectores como a los editores. Sandy Georgia ( Discusión ) 18:45, 1 de septiembre de 2020 (UTC)
- @ SandyGeorgia : Que quede claro que el uso de bots para solucionar esto no es parte de la propuesta, y por lo que he leído, la mayoría de los partidarios aquí se opondrían al uso de bots para esto. El Millo ( charla ) 18:29, 1 de septiembre de 2020 (UTC)
- Soporte : Como académico, nunca me ha gustado el estilo entre paréntesis, de todos modos, pero lo encuentro terriblemente distractor y bastante desastroso en una enciclopedia en línea, donde sería más fácil vincular a un usuario a una cita en línea que de otra manera. (Quiero decir, como usuario, no tengo tiempo para revisar todas las referencias solo para encontrar, digamos, "Público, John Q., et al." En la parte inferior de la página; y eso es lo que siempre se convierte en el estilo entre paréntesis, En última instancia. Aún así, SandyGeorgia tiene un buen punto, y espero que podamos trabajar continuamente hacia un estilo general de la casa que pueda estandarizarse para todos los usuarios. - Javert2113 ( Siarad. | ¤ ) 16:54, 1 de septiembre de 2020 (UTC)
- Agregué la palabra "a" a mi declaración anterior. - Javert2113 ( Siarad. | ¤ ) 19:59, 1 de septiembre de 2020 (UTC)
- Fuertemente apoyo : Encuentro que los estilos de referencia son fáciles de aprender y los números azules en superíndice revelan el texto de la referencia al colocar el cursor encima. Un lector puede ignorar los números en superíndice o usar su cursor y ver fácilmente las fuentes pertinentes. Usar un estilo que sea útil para escribir ensayos en papel parece evitar las ventajas de Wikipedia. No soy un experto en todas las técnicas para las referencias, pero he aprendido mucho, lo suficiente como para usar el formato corto y luego el formato completo en una lista separada para artículos largos sobre las principales novelas, y lograr que se vinculen entre sí tan fácilmente como el superíndice. enlaces numéricos a la lista de referencias. Me parece que es una buena manera de agregar las referencias, y me impulsa a encontrar la referencia completa, incluido el año, el isbn si se publicó después de 1970, el nombre de la revista si es una revista. Escribir una referencia en forma abreviada entre paréntesis crea el problema de encontrar la referencia completa en algún lugar del artículo y es difícil aprovechar las copias en línea de la referencia. Hacer que sea estándar el uso de ref y / ref me parece lógico. - Prairieplant ( charla ) 17:37, 1 de septiembre de 2020 (UTC)
- Tiempo de apoyo para deshacerse de las cosas molestas. Solo en la muerte termina el deber ( conversación ) 17:43, 1 de septiembre de 2020 (UTC)
- Apoyo. Como una especie de editor nuevo, la falta de un estilo de referencia estándar único cuando comencé a editar Wikipedia fue, con mucho, una de las partes más difíciles de adaptar del proyecto. Creo que, en general, WP: CITEVAR aumenta en lugar de reducir las barreras para los nuevos editores. Cada vez que quería contribuir a un artículo diferente, me enfrentaba a aprender un nuevo estilo de cita para que coincidiera con lo que ya existía, y era muy difícil identificar cómo las diferentes opciones se comparaban entre sí. Esta propuesta, obviamente, no resolvería ese problema, pero la menciono para respaldar la idea de que permitir muchas opciones , por definición, no facilita la referenciación para los recién llegados. El hecho de que Wikipedia teóricamente permitiera citas en línea / sin pie de página de ninguna manera simplificó mi experiencia de aprender a contribuir, a pesar de que las citas entre paréntesis en línea eran mi formato "nativo" en mi trabajo académico; por un tiempo ni siquiera sabía que estaba permitido, y cuando lo supe, aumentó mi confusión sustancialmente sobre cómo abordar las citas. Apoyo la desaprobación de las citas sin notas al pie de página, diciendo que no son las preferidas y que se alienta a los editores a convertirlas. También apoyaría agregar más funcionalidad a la plantilla de lista de referencias, como permitir que las fuentes se enumeren alfabéticamente o por fecha. También apoyaría un cambio en la documentación sobre WP: CITEVAR para expresar a los nuevos editores las ideas que he visto descritas en esta discusión, que la variación en las citas está destinada a permitir una reducción de las barreras, en lugar de un aumento de los estándares. La interpretación de reducción de barreras en CITEVAR podría enfatizarse, por ejemplo, describiendo una "cita mínima viable" (que me imagino que es 'el texto sin formato que enumerarías en una bibliografía normal, pero dentro de las etiquetas '). ~ oulfis 🌸 ( hablar ) 21:52, 1 de septiembre de 2020 (UTC)
- Quiero enfatizar que apoyo esta propuesta como un nuevo editor que es un especialista académico acostumbrado a las citas entre paréntesis en línea (el tipo de persona que veo que muchos dicen que se asustaría con la prohibición de los paréntesis en línea) y que la apoyo porque hay menos Las opciones me habrían dado una experiencia de aprendizaje más fluida al dejar en claro lo que realmente se suponía que debía aprender. Era totalmente desconcertante que una cita sin notas al pie de página pudiera ser aceptable, cuando todo lo que sabía al usar Wikipedia como lector sugería que los pequeños números azules de clic eran el estándar. ~ oulfis 🌸 ( hablar ) 22:07, 1 de septiembre de 2020 (UTC)
- Soporte . Ya están efectivamente depreciados. Además, no somos una revista científica. Las citas en línea están destinadas a un discurso altamente académico donde la verificación instantánea de las fuentes es la máxima prioridad. Somos una enciclopedia, donde las citas están destinadas a otros editores más que a los lectores en general. Adam Cuerden ( charla ) Tiene aproximadamente el 7,4% de todos los FP 22:00, 1 de septiembre de 2020 (UTC)
- Soporte Cuando las citas se hacen de esta manera, es mucho más difícil encontrar si la información es verdadera que requirió la cita en primer lugar. Andrew nyr ( charla , contribuciones ) 22:02, 1 de septiembre de 2020 (UTC)
- Apoyo : favoreciendo la segunda opción. Publico artículos universalmente usando citas entre paréntesis, y en papel está bien, pero realmente no encaja bien con Wikipedia, donde hay varias opciones superiores disponibles que no están disponibles en forma impresa. Creo que es mejor si desalentamos la práctica aquí . Dyanega ( charla ) 22:48, 1 de septiembre de 2020 (UTC)
- Apoye la eliminación gradual de las citas entre paréntesis y ajuste el MOS en consecuencia. Las notas al pie son más fáciles de leer porque no interrumpen el flujo del texto y están vinculadas automáticamente a la cita completa, y las notas al pie son más fáciles de editar porque eliminan los trabajos innecesarios de copiar y pegar y las verificaciones cruzadas manuales, así como las inevitables errores, en beneficio de los lectores y los nuevos editores, a quienes se les puede enseñar más fácilmente una forma única y consistente de formatear las referencias. ( WP: CITEVAR provoca discusiones innecesarias y desvía la atención a los tecnicismos en lugar del contenido del artículo). Si bien no tenemos que adherirnos estrictamente a una guía de estilo externa o destruir cada cita entre paréntesis a la vista, sería beneficioso para todos establecer universalmente notas al pie: un estilo coherente y de fácil acceso. ComplexRational ( charla ) 01:23, 2 de septiembre de 2020 (UTC)
- Fuerte apoyo , no hagamos que sea más difícil para nuestros lectores de lo que ya es. Ed [charla] [titán majestuoso] 02:02, 2 de septiembre de 2020 (UTC)
- Soporte por nom. Cbl62 ( charla ) 02:35, 2 de septiembre de 2020 (UTC)
- Apoyar la desaprobación. UpdateNerd ( charla ) 05:40, 2 de septiembre de 2020 (UTC)
- Soporte leve . Gracias al nominador por dar el ejemplo de Actuario como un artículo usando el estilo de cita que no creo haber visto en mis años en este sitio. Estoy de acuerdo en que el estilo se ve desordenado. No creo que tenga un gran efecto alejando a los nuevos colaboradores, siempre y cuando los que están en la línea de nuevos artículos no sean demasiado duros con los estilos de citas incorrectos, y en realidad un estilo de cita tan arcaico e inusual como este podría igualmente alejarlo. contribuyentes experimentados que tal vez no tengan idea de por qué este artículo es tan diferente del resto. // Lollipoplollipoplollipop :: talk 07:11, 2 de septiembre de 2020 (UTC)
- Oponerse a la desaprobación. Como muchos dijeron, no es asunto nuestro limitar y restringir las contribuciones. Este estilo en realidad promueve una escritura bien referenciada y verificable. Personalmente (siendo un académico) lo encuentro legible y de hecho lo prefiero (más exactamente, prefiero la referencia "mencionada por primera vez", pero esto está cerca). - Muhandes ( charla ) 08:23, 2 de septiembre de 2020 (UTC)
- Apoye el estilo preferido como notas a pie de página, pero sin hacer citas entre paréntesis "incorrectas". Personalmente, no me gustan mucho las citas entre paréntesis, pero no es descabellado que alguien las prefiera. Y lo que no quiero es alguien que contribuya con buen contenido y que se haya desconectado de la edición debido al dolor que siente por su estilo de cita. Es por eso que Wikipedia no tiene un estilo de cita establecido: valoramos la sustancia sobre el estilo. Dicho esto, debería estar perfectamente bien cambiar de paréntesis a notas a pie de página si un editor cree que mejora el artículo: el ejemplo de Actuario es un candidato perfecto para mejorar mediante un cambio de estilo de cita. Pero, si alguien se opone, entonces debería seguir la ruta tradicional: página de discusión y si la discusión se empantana sin un consenso claro, entonces el estilo actual debería prevalecer. Jason Quinn ( charla ) 09:31, 2 de septiembre de 2020 (UTC)
- Soporte Las citas en línea hacen que un artículo sea mucho menos legible. Un lector lego necesita principalmente que el artículo sea accesible e incluso que pueda escanearlo rápidamente. Los laicos solo necesitan consultar las referencias de vez en cuando, y Wikipedia es principalmente para laicos. Sin embargo, ¡la depreciación debe aplicarse a la ligera! Como mejor práctica en lugar de un requisito para los contribuyentes. Creo que debería haber una directriz sobre este tema, en lugar de tener artículos como Karlheinz Stockhausen, que necesita desesperadamente menos citas en línea, pero no tiene consenso para hacer el cambio por completo porque "las directrices de WP no lo requieren". - DTysen ( charla ) 11:34, 2 de septiembre de 2020 (UTC)
- Oponerse : la nominación y muchos de los apoyos parecen ser poco más que WP: IDONTLIKEIT . Rara vez me encuentro con un artículo al que se hace referencia de esta manera, y mucho menos a otros nuevos, y una minoría muy pequeña no justifica una prohibición puramente del gusto personal. - O Still Small Voice of Clam 19:14, 2 de septiembre de 2020 (UTC)
- Soporte condicional : esta es una buena idea, mejorará la legibilidad y mejorará la coherencia. Dicho esto, tratemos de no ser WP: JERKs si las personas adoptan viejos hábitos y ofrezcamos orientación (¿herramientas? ¿Bots?) Para ayudar a los editores a corregir el formato. Shooterwalker ( charla ) 19:25, 2 de septiembre de 2020 (UTC)
- Fuerte Oposición, según Wugapodes, DGG, Clayoquot y varios otros (incluido el comentario de Tigraan, que cuestiona las suposiciones hechas incluso por los Opositores). Esto apesta a WP: IDONTLIKEIT y cae en la trampa de asumir que lo que los editores de WP están más acostumbrados a usar es mágicamente lo mejor. Soy un académico que usa citas entre paréntesis en línea de manera profesional y no me distrae, ni interrumpe el flujo, ni un estilo que conduce a la pereza al omitir información crucial como números de página, ni un montón de otras preferencias personales y / o anecdóticas. reclamaciones de los votos / votantes de Support! Finalmente, creo que eliminar un formato de cita perfectamente aceptable solo limitará la participación de nuevos usuarios; ciertamente no va a mejorar la calidad de las citas en general, ya que la calidad de las citas tiene más que ver con la inclusión de información que con el formato de esa inclusión. A falta de datos reales que muestren lo que quieren los lectores, estos argumentos deben descartarse. Lo que nos queda son argumentos sobre lo que las citas deberían ser / transmitir, y en tal discusión, no veo una razón convincente para eliminar los paréntesis en línea. - Pinchme123 ( charla ) 19:54, 2 de septiembre de 2020 (UTC)
- Soporte en forma débil . Estoy de acuerdo en que para no desanimar a los nuevos editores, debería seguir siendo posible utilizar referencias en línea para nuevos artículos y ediciones. Si WP (1) estableció referencias vinculadas como la opción preferida y (2) por lo tanto permitió (o incluso alentó) la conversión de referencias en línea a referencias vinculadas, no puedo imaginar a muchos editores tecnológicamente poco sofisticados que se opongan al cambio resultante. SI esto se acuerda una vez aquí, no veo la necesidad de establecer un consenso por separado en cada página; Sin embargo, la conversión debe anotarse en la página de discusión con un enlace a la página de estándares. Charla Cl ea n Co py 20:29, 2 de septiembre de 2020 (UTC)
- Soporte - El hecho de que CITEVAR exista no significa que no podamos cambiarlo o deshacernos de él. Este formato puede funcionar para publicaciones académicas pero, en esos entornos, el autor a veces ofrece análisis e investigación originales (OR), para los cuales no se requiere citación. Nosotros, por política, prohibimos OR. Esto significa que, a través de WP: V , necesitamos MUCHAS citas más para colocar en el texto. Las notas a pie de página son la única forma de asegurarse de que las citas no distraigan la atención de la prosa. Otro problema es que no somos una enciclopedia impresa y nuestros artículos cambian constantemente. Esto hace que los estilos de citas entre paréntesis en línea sean inviables y casi imposibles de mejorar. Este estilo de cita es una forma de WP: OWN y se ha utilizado para evitar que los editores realicen mejoras. Las plantillas de citas en la era del editor visual son extremadamente fáciles de aprender a usar. Aprendí a usarlos en menos de 2 ediciones. El editor visual puede incluso ser la razón por la que me uní a Wikipedia y continué editando durante tanto tiempo. ¡Las notas al pie funcionan! Funcionan tan bien que considerar cualquier otro formato como una mejor opción para avanzar, incluso como una excepción, es una tontería y no nos ayudará a construir la mejor enciclopedia que podamos. Todos los artículos que utilicen este formato deben cambiarse al estilo de notas al pie sin ningún prejuicio contra el editor que en el pasado o en el futuro los utilice. Si se envía un artículo de origen sobre un tema notable con este formato en uso, el artículo debe aceptarse y luego cambiarse a notas al pie. --- C & C ( Café y migas ) 00:07, 3 de septiembre de 2020 (UTC)
- Soporte Por debajo de la línea de referencia, no me importa qué estilo se use. Sin embargo, por encima de la línea, es una historia diferente. Los paréntesis son confusos e impiden la legibilidad. Si no enlaza en línea y las citas completas, puede ser difícil encontrar fuentes y existe un riesgo mucho mayor de olvidar por completo la cita completa que si se utilizan notas a pie de página. He visto a personas mencionar estilos de citas como Bluebook (también conocido como citas legales) para justificar el uso continuo de la política entre paréntesis. Sin embargo, las citas de Bluebook son notas a pie de página, por lo que las anteriores no causan los problemas de los paréntesis en la línea anterior. Además, los tipos de fuentes que utilizaría para los artículos legales tienen información de citas única que sería difícil de reflejar con una cita estándar. Esto no es cierto para las citas entre paréntesis. He visto a algunas personas argumentar que los paréntesis son fáciles de usar para los nuevos miembros. Sin embargo, no es tan difícil escribir en
fuente y cada editor tiene una pestaña de cita en la pantalla de edición que creará citas automáticamente si ingresa la información. Spirit of Eagle ( charla ) 01:18, 3 de septiembre de 2020 (UTC) - Soporte : además de todas las demás razones, la reducción del número de estilos de citas facilita la combinación de artículos o el traslado de secciones de un artículo a otro. Deberíamos desaprobarlo, pero deberíamos invitar a los novatos a usarlo si se sienten cómodos con él y luego pedir ayuda para convertirlo a un estilo más aceptable. - Arch dude ( charla ) 01:27, 3 de septiembre de 2020 (UTC)
- Respalde los argumentos ya presentados anteriormente con respecto a la legibilidad, la coherencia y el hecho de que somos una enciclopedia digital, no una enciclopedia en papel ni una revista académica. Some1 ( charla ) 05:58, 3 de septiembre de 2020 (UTC)
- Se opone firmemente : he escrito para muchas fuentes que tienen pautas de estilo sólidas y las hacen cumplir. Wikipedia no es uno de esos, y las citas son un desastre glorioso. No puedo expresar cuán firmemente estoy en contra de la idea de que solo los documentos que están en línea sean citas válidas, lo que parece ser la lógica detrás de uno de los argumentos de algunos partidarios. Si, en el caso de un artículo en particular, las citas en línea hacen que ese artículo en particular se vuelva ilegible, eso es algo que debe analizarse en la evaluación de GA o FA. No es una prioridad para todos los artículos, especialmente en la etapa de destubificación. AKAF ( charla ) 06:06, 3 de septiembre de 2020 (UTC)
- Oposición débil - según Wugapodes. El estilo entre paréntesis es mejor para los nuevos contribuyentes, peor para los lectores.
- Dado que se adapta muy bien a algunos artículos altamente académicos, debe mantenerse como una opción válida para reducir la fricción para los nuevos usuarios. - Spacepine ( charla ) 08:56, 3 de septiembre de 2020 (UTC)
- Apoye todos y cada uno de los pasos hacia la estandarización. Ya pedimos que las adiciones a los artículos existentes conserven los estilos de citas existentes, por lo que ya estamos pidiendo a muchos usuarios nuevos que aprendan un estilo nuevo. Es mucho menos oneroso esperar que todos aprendan un estilo de casa único que esperar que todos aprendan una multitud de estilos diferentes dependiendo del artículo que estén editando. Lowercaserho ( charla ) 09:09, 3 de septiembre de 2020 (UTC)
- Oponerse por DGG y otros. Lo más importante es que el artículo tenga citas y las citas sean utilizables. De lo contrario, alienas a mucha gente. Dennis Brown - 2 ¢ 09:15, 3 de septiembre de 2020 (UTC)
- Apoye tener un estilo de cita consistente, hacia lo cual esta propuesta es un pequeño paso. Aquí se dice demasiado sobre las necesidades de los editores, pero Wikipedia no existe para los editores; existe para los lectores. Permitir una gran cantidad de estilos diferentes es como usar un estilo diferente en cada página de un libro. Deberíamos adoptar un enfoque más profesional de nuestra estructura. Zero talk 15:49, 3 de septiembre de 2020 (UTC)
- Soporte Siempre que estemos diciendo que esto es "obsoleto", de modo que 1) eliminamos el soporte de políticas / pautas / MOS para el estilo (aunque retenemos lo suficiente para establecer que alguna vez fue compatible pero ahora está desaprobado) 2) artículos existentes con la cita no tienen prisa inmediata por ser arreglados y que cambiar un estilo en un artículo aún debe estar sujeto a discusión según WP: CITEVAR ) y 3) solo después de una RFC separada para establecer algún proceso / fecha límite para pasar y establecer períodos de finalización / fechas límite después de las cuales los editores pueden pasar y comenzar a cambiar las referencias de los pares por versiones de plantillas de citas. Básicamente, no queremos que los nuevos artículos y editores utilicen este estilo. - M asem ( t ) 16:02, 3 de septiembre de 2020 (UTC)
- Soporte ya que las citas de pie de página son la mejor opción Germartin1 ( charla ) 21:03, 3 de septiembre de 2020 (UTC)
Descanso arbitrario 4 (citas)
- Oponerse . Deberíamos poder escribir artículos en un modo de edición de texto sin tener que interrumpir la escritura / el tren de pensamiento para hacer referencia a varios conjuntos arcanos de conjuntos de reglas de sintaxis de plantilla. Dcattell ( charla ) 19:23, 3 de septiembre de 2020 (UTC)
- Soporte . Utilizo principalmente citas de {{ sfn }}, pero a otras les gustan las citas de estilo . De cualquier manera, el lector ve texto que no está abarrotado de detalles de citas, pero puede hacer clic en un enlace como [12] para ver qué se está citando. Con citas entre paréntesis de tipo texto, el lector ve texto desordenado, y el desorden puede ser simplemente una fuente imaginaria agregada para hacer que un artículo basura parezca más autorizado, como en:
The Riverside Garage Girls are the sharpest prog electro rock band in the north city (Janssens 2020, p. 169).
- Las citas entre paréntesis de tipo texto son una reliquia de las torpes citas impresas de estilo antiguo. No tienen cabida en Wikipedia. Aymatth2 ( charla ) 20:58, 3 de septiembre de 2020 (UTC)
- Oponerse firmemente . Claramente perjudicial para las fuentes fuera de línea Horatius At The Bridge ( charla ) 22:23, 3 de septiembre de 2020 (UTC)
- Oponerse . Solución en busca de un problema. Dado que WP está ampliamente abierto a muchos estilos de citas diferentes, no hay ninguna razón en particular para excluir este. Wasted Time R ( charla ) 22:29, 3 de septiembre de 2020 (UTC)
- Soporte . Al mirar la sección de bibliografía, me resulta útil poder identificar dónde (o si) se usan los libros en el artículo, esto es bastante fácil de hacer si hay una sección de notas al pie, pero no si el artículo usa este estilo de cita. . EdwardUK ( charla ) 00:03, 4 de septiembre de 2020 (UTC)
- Soporte , por EdwardUK. Tener todas las notas al pie ordenadamente en la parte inferior del artículo y poder saltar de nuevo a ellas en línea es útil para el lector y, en última instancia, es la facilidad del lector en lo que deberíamos pensar. La oposición de Horatius At The Bridge no tiene sentido: si una fuente está fuera de línea o no, no influye en si se utilizan las citas entre paréntesis. He citado docenas de fuentes fuera de línea con bastante éxito usando etiquetas ref y reflists basadas en sfn; a la inversa, la horrible bestia que es Actuario utiliza citas entre paréntesis para citar sitios web. ♠ PMC ♠ (charla) 04:21, 4 de septiembre de 2020 (UTC)
- Según AKAF anterior:
"No puedo expresar cuán firmemente estoy en contra de la idea de que solo los documentos que están en línea son citas válidas, lo que parece ser la lógica detrás de uno de los argumentos de algunos partidarios ..."
Espero que eso te ayude a comprender un poco mejor mi posición Horacio At The Bridge ( charla ) 11:17, 4 de septiembre de 2020 (UTC)- Realmente no. Como dije, las fuentes fuera de línea no las citan únicamente las personas que utilizan citas entre paréntesis, y las citas entre paréntesis no se utilizan únicamente para citar fuentes fuera de línea. La validez de las fuentes fuera de línea (en ambos lados) es una pista falsa que distrae del problema real en cuestión, que es si se debe continuar permitiendo o no el uso de un estilo de cita confuso y desordenado. ♠ PMC ♠ (charla) 07:28, 5 de septiembre de 2020 (UTC)
- Eso supone que el estilo es desordenado y confuso, es decir, está planteando la cuestión . Algunos lectores quieren ver la procedencia de una idea en el acto; algunos conocen el arte de hojear y pueden leer las citas entre paréntesis casi sin problemas. Dada la poca investigación seria que se ha realizado sobre el supuesto enfoque de Wikipedia, el lector, no tenemos absolutamente ninguna idea verificable (en el sentido fáctico, no el secuestro de Wiki de ella) si estos son un positivo o negativo neto o no desde la perspectiva del lector. . Qwirkle ( charla ) 10:25, 5 de septiembre de 2020 (UTC)
- Realmente no. Como dije, las fuentes fuera de línea no las citan únicamente las personas que utilizan citas entre paréntesis, y las citas entre paréntesis no se utilizan únicamente para citar fuentes fuera de línea. La validez de las fuentes fuera de línea (en ambos lados) es una pista falsa que distrae del problema real en cuestión, que es si se debe continuar permitiendo o no el uso de un estilo de cita confuso y desordenado. ♠ PMC ♠ (charla) 07:28, 5 de septiembre de 2020 (UTC)
- Según AKAF anterior:
- Oponerse . En primer lugar, si el número de artículos que utilizan este método es tan pequeño como el OP y otros han afirmado, entonces, ¿qué problema pueden plantear a los lectores? En segundo lugar, aunque el método de Harvard ciertamente no es mi estilo preferido, y al encontrarme con uno o dos de estos artículos al principio lo encontré un poco desagradable, cuando dejé a un lado mis prejuicios, los encontré bastante fáciles de leer, y no solo eso, me di cuenta de que en realidad tienen la ventaja de que uno puede ver de un vistazo exactamente quién está siendo citado y con qué frecuencia, en lugar de tener que pasar el mouse sobre los enlaces para averiguarlo. ¿Qué tiene eso de terrible? Además, encontré el argumento de un usuario anterior de que las citas en superíndice pueden hacer que los artículos matemáticos sean confusos para ser persuasivos. Finalmente, me preocupa que desaprobar el estilo pueda desanimar a algunos usuarios de contribuir, o peor aún, alejar a algunos, dado que la gente puede estar muy apegada a sus formatos preferidos. Y después de todo, no es como si de repente vamos a tener un estilo consistente si nos deshacemos de este - la gente tiene todo tipo de enfoques diferentes dentro de los parámetros aceptados, e incluso las plantillas de citas en sí producen un formato inconsistente (como presentar fechas cerca del principio, entre paréntesis, y tenerlas cerca del final, sin paréntesis, etc.). Creo que puedo aceptar la noción de que tenemos un estilo preferido , pero desaprobar los estilos que a algunas personas simplemente no parecen gustarles no me parece una gran idea. Gatoclass ( charla ) 12:06, 4 de septiembre de 2020 (UTC)
- Colocar el mouse sobre el mouse solo funciona si tiene las ventanas emergentes habilitadas; muchos editores habilitaron las ventanas emergentes hace tanto tiempo que no se dan cuenta de que no es una opción predeterminada. Entonces, la comparación es en realidad entre tener que hacer clic en la nota al pie y ser llevado al final de la página, y luego tener que encontrar el camino de regreso (muchos lectores no sabrán presionar la flecha alt-izquierda en su navegador), o en lugar de eso, solo veo la cita allí mismo. Al igual que Johnbod, nunca utilizo citas entre paréntesis, pero para ser honesto, para aquellos lectores que se preocupan por lo que se cita una declaración , las citas entre paréntesis son probablemente la forma más conveniente de citar, no menos importante. Mike Christie ( charla - contribuciones - biblioteca ) 14:29, 4 de septiembre de 2020 (UTC)
Discusión (citas)
Pregunta: ¿qué ocurre con un nuevo editor ahora que está agregando el contenido de buena en una página usando un estilo de citación diferente a lo que está en uso en una página? - Dirk Beetstra T C 11:31, 3 de septiembre de 2020 (UTC)
- En mi experiencia, los editores que se preocupan por ese artículo convertirán la referencia al estilo establecido del artículo. - Michael Bednarek ( charla ) 12:18, 3 de septiembre de 2020 (UTC)
- Michael Bednarek , eso es lo que quiero decir. Entonces, si esto pasa, en lugar de una conversión de citas entre paréntesis al estilo de etiqueta o viceversa (dependiendo del estilo establecido), dichos artículos ahora se convertirían en unidireccionales (por lo tanto, siempre se eliminarían las citas entre paréntesis). La única diferencia puede ser que (si esto pasa) veremos que los artículos que fueron creados con citas entre paréntesis se moverán a <> - etiquetas de referencia cuando alguien tenga ganas de hacerlo. Dirk Beetstra T C 14:44, 3 de septiembre de 2020 (UTC)
- Hay muchas interpretaciones diferentes arriba de lo que significaría esta propuesta redactada de manera extremadamente vaga; no estoy seguro de que la suya haya sido articulada anteriormente, pero sin duda muchos partidarios piensan esto. Otras opiniones expresadas anteriormente por los "partidarios" incluyen: a) primero debe haber consenso en la página de discusión, b) las objeciones de la página de discusión pueden detener una conversión, c) un bot convertirá automáticamente los artículos, d) si llega a través de Afc, el artículo no lo haría ser permitido en el espacio de artículos sin conversión, e) los artículos sobre algunas áreas temáticas deben estar exentos, quizás después de discusiones individuales. Muchos partidarios solo apoyan la "desaprobación" en los artículos nuevos; los antiguos deben dejarse como en la actualidad. Estas opciones de ninguna manera agotan lo que apoyan los seguidores. Johnbod ( charla ) 15:54, 3 de septiembre de 2020 (UTC)
- Pregunta: ¿esta propuesta no es coherente tanto con el marcado wiki como con el editor visual? Ambas opciones de edición proporcionan el mecanismo para utilizar notas a pie de página, sin mencionar las citas entre paréntesis. Por ejemplo, el cuadro de edición de marcado de wiki utiliza el imperativo: "Cita tus fuentes: ", mientras que el Editor visual explica con cierto detalle cómo proporcionar citas de notas al pie: Introducción: la barra de herramientas del editor visual y Referencias de edición . Si el software ya está configurado sobre la base de citas de notas a pie de página en lugar de citas entre paréntesis, ¿no debería la política estar a favor de las citas de notas de pie de página? ¿No es esa la opción menos confusa para un nuevo editor, seguir el sistema de citas establecido por el propio software wiki? - Mr Serjeant Buzfuz ( charla ) 04:54, 4 de septiembre de 2020 (UTC)
- Respuesta: No. Aunque no me gustan y nunca utilizo los paréntesis, una gran ventaja que tienen, para los nuevos editores técnicamente nerviosos que ya están acostumbrados a ellos, es que son texto puro y no necesitan ninguna ayuda del software. Supongo que nunca ha ejecutado wikithons de entrenamiento, etc., o sabría lo desalentadores que encuentran la mayoría de los editores de primeros pasos todos los sistemas con plantillas. Johnbod ( charla ) 12:03, 4 de septiembre de 2020 (UTC)
- Pregunta: ¿esta propuesta no es coherente tanto con el marcado wiki como con el editor visual? Ambas opciones de edición proporcionan el mecanismo para utilizar notas a pie de página, sin mencionar las citas entre paréntesis. Por ejemplo, el cuadro de edición de marcado de wiki utiliza el imperativo: "Cita tus fuentes: ", mientras que el Editor visual explica con cierto detalle cómo proporcionar citas de notas al pie: Introducción: la barra de herramientas del editor visual y Referencias de edición . Si el software ya está configurado sobre la base de citas de notas a pie de página en lugar de citas entre paréntesis, ¿no debería la política estar a favor de las citas de notas de pie de página? ¿No es esa la opción menos confusa para un nuevo editor, seguir el sistema de citas establecido por el propio software wiki? - Mr Serjeant Buzfuz ( charla ) 04:54, 4 de septiembre de 2020 (UTC)
- Hay muchas interpretaciones diferentes arriba de lo que significaría esta propuesta redactada de manera extremadamente vaga; no estoy seguro de que la suya haya sido articulada anteriormente, pero sin duda muchos partidarios piensan esto. Otras opiniones expresadas anteriormente por los "partidarios" incluyen: a) primero debe haber consenso en la página de discusión, b) las objeciones de la página de discusión pueden detener una conversión, c) un bot convertirá automáticamente los artículos, d) si llega a través de Afc, el artículo no lo haría ser permitido en el espacio de artículos sin conversión, e) los artículos sobre algunas áreas temáticas deben estar exentos, quizás después de discusiones individuales. Muchos partidarios solo apoyan la "desaprobación" en los artículos nuevos; los antiguos deben dejarse como en la actualidad. Estas opciones de ninguna manera agotan lo que apoyan los seguidores. Johnbod ( charla ) 15:54, 3 de septiembre de 2020 (UTC)
- Michael Bednarek , eso es lo que quiero decir. Entonces, si esto pasa, en lugar de una conversión de citas entre paréntesis al estilo de etiqueta o viceversa (dependiendo del estilo establecido), dichos artículos ahora se convertirían en unidireccionales (por lo tanto, siempre se eliminarían las citas entre paréntesis). La única diferencia puede ser que (si esto pasa) veremos que los artículos que fueron creados con citas entre paréntesis se moverán a <> - etiquetas de referencia cuando alguien tenga ganas de hacerlo. Dirk Beetstra T C 14:44, 3 de septiembre de 2020 (UTC)
- Apoyo el punto de Johnbod sobre los novatos. Yo también he ayudado a organizar maratones de edición para nuevos editores, y confirmo que cualquier cosa que facilite sus esfuerzos tentativos y nerviosos es algo bueno. Tim riley talk 21:35, 4 de septiembre de 2020 (UTC)
- La profusión de diferentes interpretaciones anteriores es una de mis principales preocupaciones sobre esta propuesta. Podría apoyar con bastante comodidad una forma ligeramente limitada de la propuesta de Beetstra (la principal diferencia puedo pensar que es una excepción para la situación bastante poco común en la que un artículo necesita contrastar diferentes versiones de los puntos de vista de la misma persona sobre un tema, en cuyo caso ser capaz de diferenciar en línea entre, digamos, Eek (2019), Eek (2020a) y Eek (2020b) puede ser la forma más clara de hacerlo), pero los "apoyos" parecen abarcar desde algo como la propuesta de Beetstra bajo circunstancias muy limitadas desde el principio hasta insistir en {{ cite }} completo con todos los parámetros en todas las circunstancias. Y los "opuestos" parecen apenas menos variados en lo que precisamente se oponen. Prefiero simpatizar con quien tenga que tomar una decisión sobre la base de las opiniones anteriores: lo que sea que se le ocurra es probable que reciba más críticas vociferantes que un acuerdo y, de hecho, mi simpatía por ellos no necesariamente se extenderá a su decisión. PWilkinson ( charla ) 11:38, 4 de septiembre de 2020 (UTC)
- @ PWilkinson y Johnbod :, mi pregunta fue más específica. Ahora, obviamente, tiene editores que usan citas entre paréntesis en las páginas donde se usan etiquetas y "viceversa". Ahora, "presumo" que estos novatos no son crucificados, descuartizados o decapitados. Ahora, si esto pasa, desaprobaremos las citas entre paréntesis. Depreciar, no prohibir. ¿Por qué el lado opuesto tiene tanto miedo de que ellos, así como los novatos que pueden estar acostumbrados a las citas entre paréntesis, sean crucificados, descuartizados y decapitados?
- Convierto enlaces externos en línea en referencias de enlaces externos simples. No tomo el esfuerzo de convertirlos en citas entre paréntesis o referencias de citas completas. No me han crucificado, descuartizado ni decapitado. Algunos vinieron, vieron y convirtieron el dobladillo en referencias de plantillas de citas. O no. Dirk Beetstra T C 19:35, 4 de septiembre de 2020 (UTC)
- ¿Y qué significa exactamente "desaprobar"? En la práctica, los citebandits que ya han estado deambulando por WP durante años, descendiendo ilegalmente a los artículos y convirtiéndolos a su estilo preferido (generalmente sfn en estos días) harán un breve trabajo de cualquier artículo que encuentren entre paréntesis, a menudo introduciendo errores de varios tipos. Pronto estarán buscando el próximo estilo para prohibir. WP: CITEVAR ya prohíbe con razón los estilos mixtos, como reconoce anteriormente. Está claro que muchos seguidores piensan que no se permitirán nuevos artículos entre paréntesis, y muchos opositores temen que pronto se ataquen otros estilos si esto pasa. Probablemente ambos grupos tengan razón. Johnbod ( charla ) 21:43, 4 de septiembre de 2020 (UTC)
- Más o menos lo que ha dicho Johnbod , excepto que siento más simpatía por lo que está sugiriendo (y lo que creo que CaptainEek tiene la intención debajo de toda la vaguedad y aclaraciones intentadas) de lo que supongo que Johnbod . Tenemos un gran número de editores de Wikipedia entusiastas pero relativamente inexpertos que toman las pautas más recomendables, destinadas a ser aplicadas con cuidado y solo en circunstancias y formas particulares, y tratan su primera lectura apresurada como una Sagrada Escritura inquebrantable, aplicable universalmente y literalmente. En este caso, creo que la mayoría de los artículos existentes con citas entre paréntesis en línea probablemente mejorarían si esas citas estuvieran rodeadas por <> - etiquetas de referencia o modificadas en plantillas {{ sfn }} - pero también que algunos de esos artículos contendrán un número mayor o menor de tales citas, lo que requerirá una mayor sensibilidad para preservar el sentido y la gramaticalidad del texto del artículo, y algunos casos en los que esto es efectivamente imposible (por lo que es mejor guardar dichas citas); y también que a varios editores novatos les resultará más fácil, al menos al principio, que se les permita usar citas entre paréntesis en línea sin desaprobación común, manteniendo la necesidad de preocuparse por las etiquetas o plantillas a un mínimo razonable y dejándolos concentrarse en escribir el texto del artículo hasta obtienen un mayor dominio de Wikipedia. PWilkinson ( charla ) 12:49, 5 de septiembre de 2020 (UTC)
- PWilkinson , no espero que los editores se asusten mucho porque están creando artículos con 'el estilo de cita incorrecto'. Al igual que ahora, cuando un nuevo editor agrega un estilo de cita diferente al establecido en un artículo. Quizás se les informe, pero lo más probable es que alguien venga y lo convierta. Sí, habrá algunos editores que presionarán con exceso una directriz, pero he visto a otros editores engañarlos más que unirse al drama. Pero tal vez sea solo yo. Dirk Beetstra T C 13:00, 5 de septiembre de 2020 (UTC)
- Más o menos lo que ha dicho Johnbod , excepto que siento más simpatía por lo que está sugiriendo (y lo que creo que CaptainEek tiene la intención debajo de toda la vaguedad y aclaraciones intentadas) de lo que supongo que Johnbod . Tenemos un gran número de editores de Wikipedia entusiastas pero relativamente inexpertos que toman las pautas más recomendables, destinadas a ser aplicadas con cuidado y solo en circunstancias y formas particulares, y tratan su primera lectura apresurada como una Sagrada Escritura inquebrantable, aplicable universalmente y literalmente. En este caso, creo que la mayoría de los artículos existentes con citas entre paréntesis en línea probablemente mejorarían si esas citas estuvieran rodeadas por <> - etiquetas de referencia o modificadas en plantillas {{ sfn }} - pero también que algunos de esos artículos contendrán un número mayor o menor de tales citas, lo que requerirá una mayor sensibilidad para preservar el sentido y la gramaticalidad del texto del artículo, y algunos casos en los que esto es efectivamente imposible (por lo que es mejor guardar dichas citas); y también que a varios editores novatos les resultará más fácil, al menos al principio, que se les permita usar citas entre paréntesis en línea sin desaprobación común, manteniendo la necesidad de preocuparse por las etiquetas o plantillas a un mínimo razonable y dejándolos concentrarse en escribir el texto del artículo hasta obtienen un mayor dominio de Wikipedia. PWilkinson ( charla ) 12:49, 5 de septiembre de 2020 (UTC)
- ¿Y qué significa exactamente "desaprobar"? En la práctica, los citebandits que ya han estado deambulando por WP durante años, descendiendo ilegalmente a los artículos y convirtiéndolos a su estilo preferido (generalmente sfn en estos días) harán un breve trabajo de cualquier artículo que encuentren entre paréntesis, a menudo introduciendo errores de varios tipos. Pronto estarán buscando el próximo estilo para prohibir. WP: CITEVAR ya prohíbe con razón los estilos mixtos, como reconoce anteriormente. Está claro que muchos seguidores piensan que no se permitirán nuevos artículos entre paréntesis, y muchos opositores temen que pronto se ataquen otros estilos si esto pasa. Probablemente ambos grupos tengan razón. Johnbod ( charla ) 21:43, 4 de septiembre de 2020 (UTC)
Cierre de cita entre paréntesis
Antes de comenzar con el razonamiento detallado, me gustaría agradecer a los participantes de esta discusión por presentar sus argumentos bien razonados. La gran mayoría de las personas que comentaron proporcionó fundamentos de por qué pensaban como lo hicieron en lugar de simples "votos", y aunque es evidente que algunos editores de ambos lados tienen una opinión bastante fuerte sobre este asunto, la discusión no degeneró en descortesía y francotiradores. Eso es muy apreciado. Si bien las discusiones de esta naturaleza no se determinan contando manos, el nivel de apoyo y oposición tampoco es del todo irrelevante. En esta discusión, el apoyo a la propuesta por la formulación estándar (apoyo / (apoyo + oponerse)) ascendió aproximadamente al 71%. Esa es una proporción en la que generalmente se considera posible un consenso aproximado detrás de una propuesta. En este caso, tanto los partidarios como los opositores plantearon preocupaciones válidas y claramente definidas. Los partidarios expresaron principalmente la preocupación de que este estilo de cita no es (para Wikipedia) estándar, que hace más difícil distinguir entre referencias y contenido del artículo, y que confunde a los lectores acostumbrados a los métodos más comunes de referencia. Los partidarios a veces llamaron la atención sobre los artículos existentes en los que creían que este estilo de citación reducía su calidad (el actuario es un ejemplo comúnmente citado). Los opositores expresaron su preocupación de que los nuevos editores puedan desanimarse si se les dice que no usen este estilo, que algunas obras con licencia libre pueden necesitar trabajo para cambiar los estilos de referencia si se van a usar al por mayor, y que algunos editores experimentados que prefieren este estilo también pueden desanimarse por su eliminación. Muchos opositores encontraron que los comentarios hechos por Wugapodes y DGG eran particularmente acertados . Ambas partes plantearon argumentos válidos y bien razonados en apoyo de sus posiciones. En tal caso, el nivel sustancial de apoyo sobre la oposición indica que una mayoría sustancial de la comunidad está insatisfecha con este estilo de referencia. En consecuencia, esta discusión ha llegado a un consenso para desaprobar las referencias entre paréntesis en línea . Algunos puntos importantes planteados durante la discusión y con respecto a los detalles de implementación son:- Esta discusión apoya la desaprobación solo de las citas de estilo entre paréntesis directamente en los artículos. No desaprueba el uso de todo el formato de cita cuando se usa dentro de las etiquetas , ni el uso de las plantillas {{ sfn }} y {{ harv }}.
- Esta discusión no es una autorización para usar bots, scripts u otras herramientas automatizadas para cambiar artículos existentes en masa . Eso no debe hacerse sin un consenso independiente que lo respalde.
- Esta discusión proporcionó solo una propuesta aproximada para cambios de redacción particulares en la política relevante, específicamente WP: CITEVAR . La discusión debe tener lugar en las páginas de políticas relevantes, especialmente WT: CITE , para decidir sobre cambios en la redacción y, si es necesario, se pueden iniciar solicitudes de seguimiento para comentarios. Esos debates deberían centrarse en cómo , no en si deberían hacerse los cambios de redacción, ya que esta última decisión ya se ha tomado aquí. Además, WP: PAREN tendrá su texto actual reemplazado con una nota explicativa y se marcará como histórico.
- Varios, incluidos muchos que apoyan este cambio, plantearon el punto de que los artículos no deben rechazarse en AfC únicamente por el uso de citas entre paréntesis. Esta afirmación no recibió ninguna oposición sustancial.
- En los artículos existentes, se debe discutir la mejor manera de convertir las citas entre paréntesis en formatos actualmente aceptados si hay objeciones a un método en particular. No hay prisa ni necesidad de editar guerras. Sin embargo, una vez más, la discusión debería centrarse en cómo y no en si se hará el cambio, ya que esto último se decide aquí.
Una vez más, muchas gracias a los participantes aquí por sus pensamientos bien pensados y conducta ejemplar en esta discusión. Seraphimblade Háblame 18:13, 5 de septiembre de 2020 (UTC)
Problemas planteados por el bot Citation
Muchos de ustedes notarán que el antiguo bot User: Citation fue bloqueado hace unos dos meses. Después de una extensa discusión, el bloque ha revelado algunos problemas subyacentes sobre cómo manejamos las citas, que parecen carecer del consenso de la comunidad. El bloqueo inicial fue sobre el bot de Citation que desvincula las fuentes en los títulos de referencia si ya estaba vinculado a algo como un DOI u otro identificador único. Doy gracias Usuario: Levivich para la redacción de las preguntas, cuyo texto Arrebaté textualmente de WP: Botn :) CaptainEek ediciones Ho capitán! ⚓ 20:39, 5 de agosto de 2020 (UTC)
- Me opongo a la naturaleza de estas preguntas. Cada uno confunde un principio:
- ¿Deberían vincularse los títulos de las citas y, de ser así, a qué?
- ¿Deberían vincularse los títulos en las citas si ese vínculo es un duplicado de un identificador?
- ¿En qué circunstancias se debe eliminar un enlace de título de una cita, por un humano o por un bot?
- con su implementación:
- ¿Debería
|url=
ser el medio de vincular a una fuente? - ¿Debería
|url=
permitirse duplicar otro parámetro (o viceversa)? - ¿Debería permitirse a los bots tomar la decisión sobre si un enlace de título es redundante?
- ¿Debería
- - RexxS ( charla ) 14:21, 5 de agosto de 2020 (UTC)
- @ RexxS : Le invitamos a hacer las preguntas a continuación, aunque hará que cerrar todo esto sea bastante interesante. Les pregunté porque Levivich parecía haber hecho un buen trabajo resumiendo los problemas, y nadie se opuso a ellos en las últimas dos semanas que languidecieron en BOTN. Una vez más, pensé que alguien necesitaba hacer rodar la pelota, y esa persona siempre he sido yo. CaptainEek edita Ho Cap'n! ⚓ 18:46, 5 de agosto de 2020 (UTC)
- @ CaptainEek : Un cierre "interesante" suele ser consecuencia de no hacer preguntas sencillas. Levivich ciertamente hizo un buen trabajo al brindar una descripción general de las múltiples cuestiones que debían decidirse, pero eso no necesariamente constituye una buena elección para las preguntas de RpA, que deben ser lo más claras y enfocadas posible. Hice este punto en el debate anterior. Le agradezco que haya puesto la pelota en marcha, pero todavía temo que ahora sea difícil distinguir las opiniones de los editores sobre los principios generales del debate sobre cómo se podrían implementar. Es muy fácil desviar la atención de los "problemas planteados por el bot de Citation" centrándose en la codificación de citas CS1 / 2, que es una pista falsa. - RexxS ( charla ) 21:25, 5 de agosto de 2020 (UTC)
- @ RexxS : Le invitamos a hacer las preguntas a continuación, aunque hará que cerrar todo esto sea bastante interesante. Les pregunté porque Levivich parecía haber hecho un buen trabajo resumiendo los problemas, y nadie se opuso a ellos en las últimas dos semanas que languidecieron en BOTN. Una vez más, pensé que alguien necesitaba hacer rodar la pelota, y esa persona siempre he sido yo. CaptainEek edita Ho Cap'n! ⚓ 18:46, 5 de agosto de 2020 (UTC)
- Comentario : hay varias formas de vincular títulos en plantillas de citas, es decir, además de
|url=
,|chapter-url=
- para títulos de capítulos|title-link=
y, alternativamente, un enlace wiki del título|series-link=
, para títulos de series- etc
- Supongo que estos otros métodos de vinculación, y no exclusivamente
|url=
, están cubiertos por este RfC también. - Francis Schonken ( charla ) 05:23, 24 de agosto de 2020 (UTC)- @ Francis Schonken : sus comentarios para alentar a otras personas específicas que han expresado opiniones en otros lugares a traerlas aquí me parecen WP: CANVASSing . - David Eppstein ( charla ) 06:46, 24 de agosto de 2020 (UTC)
- Sin intención de sondear a personas específicas, solo tratando de llevar la discusión a un solo lugar, como lo he hecho aquí también. De todos modos, también hizo ping al otro participante en esa charla, para evitar una percepción de trato desigual. Tenga en cuenta que ese otro participante en esa sección de la página de discusión, es decir, Trappist the monk, ya había sido pinchado aquí (por Headbomb) , sin que nadie lo considerara, aparentemente, un ping selectivo que invita a participar aquí. - Francis Schonken ( charla ) 07:04, 24 de agosto de 2020 (UTC)
- Estaba 100% inconsciente de esta discusión hasta ahora, pero que posiblemente sea mi propia incompetencia, he agregado un enlace en la página de discusión del bot de citas. AManWithNoPlan ( charla ) 20:52, 24 de agosto de 2020 (UTC)
- @ AManWithNoPlan : se le notificó de esta discusión (vía ping) el 5 de agosto ; y publiqué un enlace a este RfC en curso en la página de discusión del bot el 22 de agosto . - Francis Schonken ( charla ) 04:14, 25 de agosto de 2020 (UTC)
- Estaba 100% inconsciente de esta discusión hasta ahora, pero que posiblemente sea mi propia incompetencia, he agregado un enlace en la página de discusión del bot de citas. AManWithNoPlan ( charla ) 20:52, 24 de agosto de 2020 (UTC)
- Me gustaría enfatizar que a pesar de que fui invitado a esta discusión, no me influyó. Ya tenía respuestas sin terminar en mi carpeta de borradores durante más de una semana y simplemente me faltaba tiempo para finalizarlas.
- Como observación general, me gustaría ver un pensamiento mucho más constructivo y orientado a soluciones, supuestos de buena fe y menos wikilawyering. No es bueno para nuestra cultura de comunicación y no para el proyecto.
- - Matthiaspaul ( charla ) 13:44, 1 de septiembre de 2020 (UTC)
- Sin intención de sondear a personas específicas, solo tratando de llevar la discusión a un solo lugar, como lo he hecho aquí también. De todos modos, también hizo ping al otro participante en esa charla, para evitar una percepción de trato desigual. Tenga en cuenta que ese otro participante en esa sección de la página de discusión, es decir, Trappist the monk, ya había sido pinchado aquí (por Headbomb) , sin que nadie lo considerara, aparentemente, un ping selectivo que invita a participar aquí. - Francis Schonken ( charla ) 07:04, 24 de agosto de 2020 (UTC)
- @ Francis Schonken : sus comentarios para alentar a otras personas específicas que han expresado opiniones en otros lugares a traerlas aquí me parecen WP: CANVASSing . - David Eppstein ( charla ) 06:46, 24 de agosto de 2020 (UTC)
- Comentario : temo que el bot, al desvincular el título de forma continuada (ver p . Ej. [2] ) durante el transcurso de este RfC (del cual aún no se conoce el resultado) estaría creando una situación de hecho consumado inadvertido en muchas páginas . Consulte también WP: ANI # Citation bot . - Francis Schonken ( charla ) 04:40, 25 de agosto de 2020 (UTC)
- Pregunta El bot se detuvo el 2020-06-08 pero comenzó de nuevo el 2020-08-16. ¿Debería seguir ejecutándose durante esta discusión? - GhostInTheMachine me habla a las 21:02, 3 de septiembre de 2020 (UTC)
Enlace de título
1. ¿Deben estar vinculados los títulos de las citas y, en caso afirmativo, a qué (en otras palabras, a qué debería incluirse |url=
)?
- El título debe estar vinculado a versiones completas gratuitas de los registros cuando sea posible, con enlaces de pago como una segunda opción distante. Sin embargo, eso no significa que
|url=
deba completarse si es redundante para un identificador. En el caso de una versión completa gratuita del registro, el identificador debe marcarse como libre, de modo que el título se vincule automáticamente. Si el identificador no se vincula a la versión completa completa del registro, también se puede proporcionar, pero no en|url=
. Hay una implementación parcial para esto en CS1, pero debería implementarse por completo. Headbomb { t · c · p · b } 01:46, 5 de agosto de 2020 (UTC) - Sí , a una copia gratuita de la fuente o lo más parecido a ella. "Haga clic en el título, vaya a la fuente" es algo que todo lector sabe y espera, y deberíamos proporcionárselo. Si hay una versión gratuita (sin copyvio) de la fuente, debe estar vinculada bajo el título. Si no lo hay, una copia de la fuente que proporciona una vista previa gratuita, si está disponible (por ejemplo, Google Books o Amazon Books). O, a una copia "oficial" de la fuente, si no hay una copia gratuita disponible (por ejemplo, lo que señale el DOI). O, a una entrada del catálogo de la biblioteca, para ayudar al lector a obtener la fuente (por ejemplo, la entrada de Worldcat). Todo lo que podamos hacer para llevar al lector a la fuente, eso es lo que debería estar vinculado bajo el título en una cita. Le v ! v ich 01:47, 5 de agosto de 2020 (UTC)
- Los títulos deben estar vinculados siempre que haya texto completo gratuito, ya que eso es lo que nuestros lectores esperan encontrar en los títulos vinculados. Nuestros lectores no necesariamente saben qué es un PMC, PMID, DOI, SCID o cualquier otro identificador, pero saben que si ven un título azul, pueden esperar leer el texto completo gratuito. Los títulos NO deben estar vinculados cuando SÓLO duplican un resumen disponible en un DOI. PMC debe continuar vinculando automáticamente al título, y los editores deben poder agregar manualmente vínculos de texto completo gratuitos a través del parámetro de URL que no son copyvios pero que son texto completo gratuito. Los títulos NO deben enlazar con listados de libros como en amazon o google books a menos que el texto completo gratuito esté disponible; si la página está disponible en línea, se puede vincular en el parámetro de página. Sandy Georgia ( Discusión ) 01:49, 5 de agosto de 2020 (UTC)
- ¿Qué tan seguros estamos de que los lectores sepan título azul = texto completo gratuito? He preguntado a varios académicos que son usuarios habituales de Wikipedia si saben por qué algunos árbitros tienen los títulos vinculados y otros no. Ninguno lo supo. Adrian J. Hunter ( charla • contribuciones ) 06:57, 5 de agosto de 2020 (UTC)
- Es posible que no esperen que se dirija exclusivamente al texto completo y gratuito, pero creo que la gente se da cuenta de que está destinado a llevarlos al artículo / fuente (con muro de pago o de otro tipo). WhatamIdoing ( charla ) 14:59, 5 de agosto de 2020 (UTC)
- ¿Cómo puedes ser un académico sin saber cómo buscar qué es DOI, HDL, PMID, PMC, ArXiv, ProQuest, ISBN, OCLC, etc. Es simplemente alucinante que alguien que se supone que es bueno investigando y buscando cosas pueden simplemente lanzar sus manos a qué enlace hacer clic en función de sus suscripciones institucionales y acceso. - Chris Capoccia 💬 18:37, 6 de agosto de 2020 (UTC)
- HDL significa "lipoproteína de alta densidad", ¿verdad? No esperaría que nadie reconociera la jerga de un campo no relacionado. WhatamIdoing ( charla ) 00:09, 7 de agosto de 2020 (UTC)
- ya hay una forma clara de notar si algo es texto libre y son los varios íconos agregados con parámetros como url-access, doi-access, etc. El enlace del título no significa que sea texto libre. solo significa que alguien completó el parámetro url con algo. incluso podría haber estado poblado con un enlace roto. - Chris Capoccia 💬 14:31, 5 de agosto de 2020 (UTC)
- Dudo que muchos lectores sepan lo que significan esos pequeños iconos. WhatamIdoing ( charla ) 14:57, 5 de agosto de 2020 (UTC)
- Todo lo que necesita es pasar el mouse rápidamente y la información sobre herramientas le dirá lo que significan. - Chris Capoccia 💬 20:11, 6 de agosto de 2020 (UTC)
- Más de la mitad de nuestros lectores no tienen mouse, mouse over ni información sobre herramientas. - RexxS ( conversación ) 21:54, 6 de agosto de 2020 (UTC)
- En el dispositivo móvil, todavía preferiría hacer clic en el parámetro, ya que tengo una idea de adónde me lleva. El enlace del título no muestra ni siquiera un dominio antes de ir allí en el móvil. - Chris Capoccia 💬 22:47, 6 de agosto de 2020 (UTC)
- Más de la mitad de nuestros lectores no tienen mouse, mouse over ni información sobre herramientas. - RexxS ( conversación ) 21:54, 6 de agosto de 2020 (UTC)
- Todo lo que necesita es pasar el mouse rápidamente y la información sobre herramientas le dirá lo que significan. - Chris Capoccia 💬 20:11, 6 de agosto de 2020 (UTC)
- Dudo que muchos lectores sepan lo que significan esos pequeños iconos. WhatamIdoing ( charla ) 14:57, 5 de agosto de 2020 (UTC)
- ¿Qué tan seguros estamos de que los lectores sepan título azul = texto completo gratuito? He preguntado a varios académicos que son usuarios habituales de Wikipedia si saben por qué algunos árbitros tienen los títulos vinculados y otros no. Ninguno lo supo. Adrian J. Hunter ( charla • contribuciones ) 06:57, 5 de agosto de 2020 (UTC)
- Sí . Vinculamos el título del artículo de otras fuentes (periódicos, sitios web), por lo que no hay razón por la que no deberíamos hacerlo también para artículos de revistas. Los lectores no deberían tener que seguir una colección aleatoria subrayada en azul de dígitos y letras (un código). En cuanto a vincular solo a artículos gratuitos, puede ser la única opción en este momento para ayudar al lector a evitar la decepción de que no vale la pena hacer clic en el vínculo proporcionado. Si tuviéramos una mejor manera (¿ícono?) Para indicar los enlaces de pago (que también se aplica a los periódicos), entonces esto podría ser un problema menor. - Charla de Colin ° 09:27, 5 de agosto de 2020 (UTC)
- Otro : esta pregunta se formula de manera confusa. La URL solo debe rellenarse con algo único que no sea un duplicado de los parámetros. El lugar para quejarse sobre el acceso a los parámetros = gratis sin crear un enlace de título es en CS1. por ejemplo, doi-access = free actualmente crea un enlace de título desde el doi. podría haber algo similar para s2cid-access = free. Los usuarios no son estúpidos. pueden hacer clic en más lugares además del título. Estará perfectamente bien para muchos artículos que no se muestre ningún enlace de título. Esto no es diferente a los libros. muchos libros solo tienen ISBN y los usuarios no tienen problemas para hacer clic en él y navegar hasta cómo quieren encontrar el libro. - Chris Capoccia 💬 12:07, 5 de agosto de 2020 (UTC)
- Sí según SandyGeorgia. Está bien hacer un identificador, pero si hay una versión gratuita, debe estar vinculado en el título, ya sea que haya o no un identificador que también se vincule a la versión gratuita. - Ealdgyth ( charla ) 13:40, 5 de agosto de 2020 (UTC)
- Sí. El título de una cita es el lugar donde los lectores están acostumbrados a encontrar un enlace a la fuente. Aparte de un enlace a una infracción de derechos de autor, no hay una buena razón para eliminar un enlace del título. El enlace del título debe ir a la versión más útil de la fuente disponible . Este es un principio diferente de su implementación (a través de uno u otro parámetro, que es irrelevante para el principio). - RexxS ( charla ) 14:14, 5 de agosto de 2020 (UTC)
- Sí , prefiero tener enlaces en el título, incluso si son "duplicados" y "redundantes". Prefiero tener la URL más útil, pero "más útil" depende de las circunstancias del lector, así que al final, cualquier enlace que tenga sentido para el editor está bien para mí. Y antes de que nos preocupemos demasiado por nada de esto, tomemos un momento para recordar que casi nadie lee las referencias, y cuanto mejor es el artículo, menos referencias hacen clic. Así que hagamos algo sensato, pero no gastemos demasiado esfuerzo tratando de lograr la perfección, y definitivamente no gritemos a otros editores por poner el enlace duplicado y redundante "incorrecto" en la URL. WhatamIdoing ( charla ) 15:04, 5 de agosto de 2020 (UTC)
- Pregunta equivocada . Los títulos deben estar vinculados cuando la fuente es una URL que se usa como referencia. Los títulos no deben estar vinculados cuando la referencia está fuera de línea. Los títulos de las referencias disponibles tanto en línea como fuera de línea a veces se pueden vincular como cortesía para los lectores. Los títulos de las referencias que tienen mejores identificadores en línea que las URL, como dois o hdls, probablemente no deberían estar vinculados en mi opinión, porque el vínculo es redundante, pero sé que otros no están de acuerdo. Los títulos no deben estar vinculados cuando el vínculo va a una versión preliminar de una publicación a la que le falta la información que se utiliza para obtener la referencia. La respuesta real es "depende" y que no podemos hacer una regla para este tipo de cosas porque cualquier regla que hagamos se rompería. Al final, no hay sustituto para la inteligencia y el juicio editorial humano. Tratar de reemplazar el juicio y la inteligencia por reglas es un error. - David Eppstein ( charla ) 06:38, 6 de agosto de 2020 (UTC)
- Sí , el título debe enlazar con la fuente "mejor" (más útil, gratuita si está disponible, etc.) si está en línea. No veo ningún problema con los enlaces duplicados: si alguien conoce o se preocupa por los identificadores en línea y desea visitarlos directamente, esos enlaces están disponibles para que haga clic específicamente en ellos. El juicio humano será necesario en muchos casos para determinar el "mejor" vínculo, y en esos casos un humano puede poner eso en el
url=
campo; una vez que se completa, un bot no debería eliminarlo incluso si duplica uno de los enlaces de identificación en línea. Si no hay una URL elegida manualmente, estoy de acuerdo con que el título se vincule automáticamente a una de las URL de identificación en línea, si hay alguna disponible. Estoy de acuerdo con WAID anterior en que realmente no deberíamos pensar demasiado / complicar demasiado esto. C Thomas 3 ( charla ) 20:30, 6 de agosto de 2020 (UTC) - Ninguna Wikipedia es una enciclopedia, no un motor de búsqueda. Es el texto de los artículos el principal resultado, no las referencias, a las que los lectores prestan poca atención. Ya estamos viendo intentos agresivos de bots para insertar enlaces de spam; tratando de atraer a los lectores a su sitio en lugar de a la competencia (por ejemplo, Google Books vs Internet Archive, ninguno de los cuales escribió o publicó los libros que ahora están afirmando). No deberíamos fomentar esto. Andrew 🐉 ( charla ) 11:55, 7 de agosto de 2020 (UTC)
- sí, debería haber un enlace si se puede hacer referencia al artículo en línea, pero no siempre es necesario. No importa si el acceso es gratuito o no, pero deberíamos preferir el acceso gratuito donde se puede proporcionar. Graeme Bartlett ( charla ) 12:00, 7 de agosto de 2020 (UTC)
- Sí , enlace de título a la referencia real utilizada para la cita. No hay daño en la duplicación. · · · Peter Southwood (charla) : 14:28, 7 de agosto de 2020 (UTC)
- No : la wikipedia está sobrevinculada tal como está. Un título vinculado es un vínculo de más. —¿Philoserf? ( charla ) 08:36, 8 de agosto de 2020 (UTC)
- Sí , y a la página específica en cuestión cuando sea posible. Adam Cuerden ( charla ) Tiene aproximadamente el 7,4% de todos los FP 22:39, 9 de agosto de 2020 (UTC)
- Los títulos deben estar vinculados siempre que haya una versión en línea de la fuente disponible que no sea un copyvio. Si hay una versión de lectura gratuita completa, el enlace debería ir a esa. si no hay una versión totalmente gratuita, pero hay una versión con parte de la fuente gratuita, como un resumen, el título debe enlazar con eso. A falta de cualquiera de ellos, el título debería vincularse a una versión con muro de pago completo. Todo eso debería ser cierto independientemente de si el enlace del título va o no al mismo lugar que el enlace de algún identificador. DES (charla) DESiegel Contribs 00:57, 12 de agosto de 2020 (UTC)
- No lo se . Durante incontables años he estado vinculando los nombres de los artículos a la fuente en la que los encontré. Aquí se puede ver un ejemplo de mi práctica . Algunas han estado en JSTOR o persee.fr, otras en academia.edu, algunas revistas tienen un sitio web con copias gratuitas, como Bulletin of the American Society of Papyrologists , y algunas con fuentes un poco más esquemáticas. (No, ninguno para SciHub, ni planeo hacerlo. Al menos no todavía). Siempre sentí que esto no era del todo correcto, ya veces pensé que establecer una fuente como JSTOR o doi por separado se vería más profesional; coincidiría con la práctica actual con la plantilla ISBN; Por supuesto, si alguna vez envié un artículo que escribí en gran parte al proceso de GA o FA, tendría que reescribirlo de antemano para usar una de estas plantillas, así que ahí está. Por último, debo admitir que ninguno de los votos anteriores me ha convencido de continuar con mi práctica o de cambiarla. - llywrch ( charla ) 06:36, 12 de agosto de 2020 (UTC)
- Sí , si hay un enlace URL insertado en la plantilla, debe mostrarse en el título, a pesar de todos los demás identificadores. Así, al hacer clic en el título, accedes al enlace insertado por los editores. - Anas1712 ( charla ) 00:00, 13 de agosto de 2020 (UTC)
- Pregunta incorrecta ... Los módulos deben usarse para generar URL cuando hay una versión de texto completo, como | pmc-access o | doi-access. No, normalmente no debería haber ningún enlace a una fuente de pago en la URL porque no ayuda a nuestros lectores, muy pocas personas están dispuestas a pagar $$$ para consultar una referencia de WP. (A menos que el contenido pueda verificarse en una vista previa o no haya otro identificador para identificar de forma única la fuente). ( t · c ) buidhe 03:29, 13 de agosto de 2020 (UTC)
- Ejemplo : estaba leyendo la extinción del holoceno . Quería leer una de las fuentes. La referencia de la cita se ve así:
Ceballos, Gerardo; Ehrlich, Paul R. (8 June 2018). "The misunderstood sixth mass extinction". Science. 360 (6393): 1080–1081. Bibcode:2018Sci...360.1080C. doi:10.1126/science.aau0191. OCLC 7673137938. PMID 29880679.
No sé en cuál hacer clic. Resulta que ninguno es gratuito, pero el segundo (doi) te llevará a una vista previa de la primera página. Ese segundo debería ser el enlace del título, por lo que nadie más tiene que comprobar los cuatro para averiguarlo. Agregaré el
|url=
a esta cita. Espero que no aparezca ningún bot y lo elimine porque duplica un identificador. :-) Le v! V ich 04:10, 16 de agosto de 2020 (UTC) - Sí . El título de una cita es el lugar más intuitivo para que los lectores encuentren un enlace a la fuente, y no se debe esperar que comprendan toda la ensalada de palabras de la cita para averiguar dónde podría estar el enlace. Si no hay una fuente gratuita disponible, debería enlazar con la más útil, y esa debería quedar a discreción del editor. ¡Boing! dijo Zebedee ( charla ) 16:33, 17 de agosto de 2020 (UTC)
- Sí , al enlace más útil y, en su defecto, al menos al enlace WP: SAYWHEREYOUGOTIT , según la guía actual, si esa fue la fuente del contenido que se agregó al artículo. - Francis Schonken ( charla ) 04:28, 24 de agosto de 2020 (UTC)
- Sí, pero la pregunta simplifica demasiado . Los títulos, siempre que estén disponibles, deben estar vinculados al recurso en línea más relevante, específico y adecuado . Si bien es bueno si el enlace apunta a un recurso gratuito , ser gratuito no es (y nunca fue) un requisito para que se proporcione un enlace, sin embargo, ser relevante en el contexto de la cita sí lo es. Por defecto, el enlace debe apuntar al lugar donde la fuente citada fue encontrada por el editor que agregó una cita para satisfacer nuestro principio básico de verificabilidad ( WP: V ). Si resulta ser un enlace de pago o limitado de otras formas, esto puede dificultar la verificación para los lectores, pero esto es irrelevante con respecto a ser un enlace adecuado en una cita o no. Si hay varios enlaces disponibles, el editor debe decidir qué enlace incluir, idealmente sería un enlace profundo al documento real (por ejemplo, un PDF, ZIP, etc.), no solo a una metapágina, porque el El documento en sí es lo más relevante en cuanto a verificabilidad y el interés de los lectores que quieran estudiar ese recurso. Idealmente, este documento debería archivarse y también debería
|archive-url=
proporcionarse un enlace. Dado que los enlaces archivados no se pueden proporcionar para los enlaces de identificación, ya que|archive-url=
y|url=
deben permanecer sincronizados, y también porque los enlaces de identificación a menudo apuntan a metapáginas en lugar del documento real que respalda una declaración, el enlace asociado con el título debe ser proporcionado por|url=
y tener prioridad sobre los enlaces secundarios derivados de los parámetros del identificador. (Lo mismo para|chapter-url=
.) Entonces, idealmente,|url=
apuntaría al documento real, y los enlaces identificadores más abajo en la cita apuntarían a varias metapáginas que brindan contexto adicional (y de las cuales las instancias del documento real generalmente también están disponibles). Sin embargo, si el documento real ya hubiera sido proporcionado por un enlace profundo a través de uno de los identificadores proporcionados,|url=
posiblemente podría proporcionar una fuente alternativa (mejor calidad, más barata, alternativa, etc.) para el documento (como un enlace de conveniencia) o a otra página relevante que ya no está cubierta por los enlaces del identificador. Entonces, lo que es mejor para el interés de los lectores y del proyecto en cuanto a verificabilidad, legibilidad, integridad, estabilidad, disponibilidad, etc., en realidad depende de las circunstancias, y es necesario aplicar el buen sentido común en una cita por cita. base. - Matthiaspaul ( charla ) 20:00, 24 de agosto de 2020 (UTC) - Algunas personas están respondiendo a la pregunta incorrecta , pero no todas. Esta discusión no se trata de eliminar todos los enlaces de título, solo los redundantes. AManWithNoPlan ( charla ) 11:30, 25 de agosto de 2020 (UTC)
- Si lee lo que la gente le dice en esta sección, se dará cuenta de que no hay enlaces de título redundantes. Los enlaces de título, cuando estén disponibles, son deseables y su bot no debería eliminarlos. - RexxS ( conversación ) 22:22, 25 de agosto de 2020 (UTC)
- Yo tenía los leo y estoy en lo correcto acerca de algunos . Me equivoqué para señalar quién, dado que sería de mala educación aplastar las contribuciones de la gente durante una discusión y confío en que cualquier escrutinio de votos no sea tan estúpido como para sumar sí y no . AManWithNoPlan ( charla ) 00:51, 27 de agosto de 2020 (UTC)
- Si lee lo que la gente le dice en esta sección, se dará cuenta de que no hay enlaces de título redundantes. Los enlaces de título, cuando estén disponibles, son deseables y su bot no debería eliminarlos. - RexxS ( conversación ) 22:22, 25 de agosto de 2020 (UTC)
- A menudo es imposible decir dónde lo obtuvo o, más correctamente, agregue personas y los bots agreguen más identificadores, no hay forma de que un lector pueda saber esto. Muchas citas comienzan con un DOI y luego alguien agrega la URL (puerta de búsqueda, identificadores, etc.) o viceversa. Solo mirando el registro de edición puede encontrar dónde está la primera referencia en el sentido WP: SAYWHEREYOUGOTIT . PERO, eso solo le dice a la primera persona que lea la referencia. No tienes idea de cómo lo encontraron los editores posteriores. En segundo lugar, es posible que el editor original haya utilizado una URL de editor y luego se haya vinculado a pubmed porque el PMID estaba en la URL. AManWithNoPlan ( charla ) 16:14, 28 de agosto de 2020 (UTC)
- Sí, utilizando el parámetro de enlace de título, URL para la flecha en la que se puede hacer clic . Los títulos en las citas deben estar vinculados a un artículo de Wikipedia sobre esta fuente utilizando el parámetro title-link (p. Ej. | Title-link = The Great Gatsby) y solo en este caso el título debe aparecer en azul (no es un caso común). Al hacer clic en la flecha después del título, se debe abrir el sitio web definido en el parámetro Url (por ejemplo, | url = https: //archive.org / ...) que muestra la página de título del texto fuente. Se pueden proporcionar otros identificadores únicos como DOI, ISBN, JSTOR, etc. pero siempre además de la URL, ya que el lector puede no entenderlos. El bot puede actualizar o corregir la URL, pero nunca debe eliminarla. Johannes Schade ( charla ) 16:12, 31 de agosto de 2020 (UTC)
Vinculación duplicada
2. ¿Deberían vincularse los títulos en las citas si ese vínculo es un duplicado de un identificador (DOI, PMC, PMID, etc.) (en otras palabras, deberíamos tener |url=
incluso cuando es un duplicado de, por ejemplo, |doi=
)?
- No , en el sentido de que tener un duplicado es una redundancia inútil. Es por eso que tenemos , para marcar el DOI como libre y vincularlos automáticamente, y eliminar la duplicación necesaria. Headbomb { t · c · p · b } 01:41, 5 de agosto de 2020 (UTC)
|url=https://doi.org/...
|doi=
|doi-access=free
- Sí, si y solo si el DOI, PMC o lo que sea que contenga texto completo de libre acceso, no si es solo un resumen o el texto completo tiene un muro de pago. Sandy Georgia ( Discusión ) 01:50, 5 de agosto de 2020 (UTC)
- Sí , los títulos deben estar vinculados incluso si el vínculo duplica un identificador como DOI, e independientemente de si es gratuito o de pago. El lector sabe y espera hacer clic en el título para acceder a la fuente. El lector probablemente no sabrá cuáles son los enlaces marcados como "DOI", "PMC", etc. Incluso si colocamos símbolos de candado junto a ellos para identificar cuáles son gratuitos, y enlaces a "DOI" y "PMC", etc., para explicar cuáles son, esto es solo pedirle al lector que trabaje más para llegar al fuente: (1) tienen que saber qué son DOI / PMC o buscarlo, (2) si hay más de uno, tienen que elegir en cuál hacer clic, (3) si algunos son gratuitos y otros son Paywall, tienen que aprender qué significan los símbolos de candado, y (4) si hay más de uno libre, tienen que elegir en cuál de ellos hacer clic. "Haga clic en el título, vaya a la fuente" es lo que el lector sabe y espera; si la misma cosa está vinculada en otra parte de la cita es irrelevante para el lector. Somos nosotros, los editores, quienes debemos "elegir" qué versión de la fuente es la "mejor" versión para el lector, y debemos poner eso como un enlace debajo del título. Entonces el lector simplemente sabe que debe hacer clic en ese para llegar al mejor. E incluso si no es gratis, sabrán que ese es el lugar donde pueden obtener una copia. Además de las razones para vincular el título, realmente no hay razones AFAIK para no vincular el título a la mejor fuente disponible: ¿a quién le importa si el enlace del título duplica un identificador? Le v ! v ich 01:54, 5 de agosto de 2020 (UTC)
- Sí . Los lectores habituales asumen que al hacer clic en el enlace de un título, accederán a ese documento. Es posible que no sepan qué es un "DOI" y qué se consigue al hacer clic en él. - Finnusertop ( charla ⋅ contribuciones ) 08:54, 5 de agosto de 2020 (UTC)
- Sí y no según Sandy. - Charla de Colin ° 09:22, 5 de agosto de 2020 (UTC)
- Colin mi respuesta tuvo un Sí y un No. Por favor, aclare. Sandy Georgia ( Discusión ) 18:58, 13 de agosto de 2020 (UTC)
- Otros solo a modo de parámetro - acceso = gratuito. por ejemplo, doi-access = free. Las URL que duplican los parámetros no se deben completar manualmente en la URL y los bots deben tener la libertad de eliminar las URL duplicadas y mover las URL a los parámetros. - Chris Capoccia 💬 12:09, 5 de agosto de 2020 (UTC)
- Sí, según Sandy y Colin. - Ealdgyth ( charla ) 13:41, 5 de agosto de 2020 (UTC)
- Ealdgyth mi respuesta fue un sí y un no; por favor aclare. Sandy Georgia ( Discusión ) 18:58, 13 de agosto de 2020 (UTC)
- Sí, los vínculos de los identificadores no son relevantes para la mayoría de los lectores y el título de la cita siempre debe vincular a la fuente en línea más útil que no sea una violación de los derechos de autor. La pregunta entre paréntesis hace suposiciones sobre la implementación que pueden o no ser ciertas y enturbia las cuestiones, lo que debería ser un principio claro. - RexxS ( charla ) 14:26, 5 de agosto de 2020 (UTC)
- Sí , prefiero incluir una URL "duplicada". Si un editor ha colocado una URL "duplicada" en la cita, generalmente no debe eliminarse por ser redundante. WhatamIdoing ( charla ) 15:08, 5 de agosto de 2020 (UTC)
- Prefiero no, pero reconozco que otros editores pueden estar en desacuerdo. Este no es el tipo de cosas sobre las que necesitamos reglas. Siempre que sea coherente dentro de un artículo, WP: CITEVAR debería controlar. En particular, no deberíamos piratear plantillas de citas para forzar a un lado de este debate a salirse con la suya, y no deberíamos utilizar robots para agregar o eliminar estos enlaces. Por cierto, es importante reconocer que algunas citas vinculadas a doi NO TIENEN UN TÍTULO al que se pueda vincular una URL, y son válidas como citas con un doi, pero se vuelven inválidas si se agrega una URL; Un error en algunas plantillas de citas relacionado con esto que rompió las referencias en varios artículos se solucionó solo esta semana. - David Eppstein ( charla ) 06:40, 6 de agosto de 2020 (UTC)
- Sí , creo que es importante no eliminar una URL que se haya colocado deliberadamente en el
url=
campo, independientemente de si duplica una de las otras URL disponibles. Incluso si el comportamiento de la plantilla es tal que el enlace deseado seguirá apareciendo sin la URL explícita, puede que no siempre sea así: por ejemplo, un enlace diferente puede ser sustituido automáticamente si se agrega un nuevo identificador, o alguien puede cambiar el comportamiento predeterminado de la plantilla. La única ventaja que veo de eliminar el enlace es ahorrar unos pocos bytes de espacio de almacenamiento. C Thomas 3 ( charla ) 20:43, 6 de agosto de 2020 (UTC) - Sí, no es necesario eliminarlo si un ID formateado duplica el enlace. Pero tampoco es necesario agregar un enlace idéntico más adelante si algo como DOI lo cubre. La URL, si se proporciona, es la que utilizó el proveedor de referencia para acceder a la página. Graeme Bartlett ( charla ) 12:02, 7 de agosto de 2020 (UTC)
- Los enlaces sin sin formato son inferiores a los identificadores persistentes porque tienden a romperse con el tiempo. Y, de nuevo, Wikipedia es una enciclopedia, no un motor de búsqueda. Andrew 🐉 ( charla ) 12:06, 7 de agosto de 2020 (UTC)
- Sí, vincule el título a la fuente que se utilizó. No hay problema si duplica un DOI. No es necesario si DOI está allí desde el principio, pero no lo elimine si existe. · · · Peter Southwood (charla) : 15:14, 7 de agosto de 2020 (UTC)
- No : la wikipedia está sobrevinculada tal como está. Un enlace redundante es un enlace de más. —¿Philoserf? ( charla ) 08:36, 8 de agosto de 2020 (UTC)
- Sí , esta es una mejora de WP: V. Reducir los pasos entre los lectores y las fuentes es algo bueno, y un enlace en el título es más accesible para aquellos que no están familiarizados con los identificadores persistentes. (Si un campo que no sea url = vincula automáticamente el título a una página web específica, encuentro que se obtiene el mismo resultado para el lector y no tengo ninguna opinión sobre si url = es preferible si se vincularía exactamente a la misma página). CMD ( charla ) 17:25, 9 de agosto de 2020 (UTC)
- Sí. Es más sencillo y, a menudo, puede evitar varios clics para acceder a un texto. Adam Cuerden ( charla ) Tiene aproximadamente el 7,4% de todos los FP 22:43, 9 de agosto de 2020 (UTC)
- Sí El enlace del título siempre debe estar presente, incluso si duplica exactamente un enlace de identificación. Si este enlace será generado automáticamente por la plantilla / módulo en función de los otros parámetros, el
|url=
parámetro puede dejarse en blanco (o mejor, establecer un comentario HTML que explique por qué está en blanco), pero el enlace del título siempre debe estar presente. incluso si es redundante para un enlace de identificador. DES (charla) DESiegel Contribs 01:03, 12 de agosto de 2020 (UTC) - No se . Por Headbomb. - Bsherr ( charla ) 02:17, 12 de agosto de 2020 (UTC)
- Depende , si la URL es solo "doi.org" o similar, no. Pero si el enlace es el de la página del artículo en el sitio web de la revista académica, entonces creo que no es necesario eliminarlo, incluso si está duplicando el parámetro "Doi". De hecho, en varios casos, la inserción de la dirección web del trabajo en cuestión permite agregar la fecha de acceso. Sin embargo, cuando aplicamos CitationBot en una página de Wikipedia, la mayoría de las veces, en los casos mencionados anteriormente, la URL y la fecha de acceso se eliminan. Por lo tanto, no podemos saber cuándo se agregó la referencia. - Anas1712 ( charla ) 00:00, 13 de agosto de 2020 (UTC)
- Las fechas de acceso no son relevantes para artículos publicados en fechas específicas. Si accedió a doi : 10.1007 / lrr-2016-1 hace 2 años, si accede hoy, o accede a él en 2 años, siempre se le presentará la misma versión del documento. Las fechas de acceso son relevantes para los sitios web que pueden cambiar, como esta historia para NY Times . Si accede a él en tres días, es posible que no vea el mismo contenido que está viendo ahora. Headbomb { t · c · p · b } 20:30, 25 de agosto de 2020 (UTC)
- [ Un poco fuera del tema ] Curiosamente, la documentación de las reclamaciones de {{ Cite web }}
"No se requieren fechas de acceso para los enlaces a ... artículos de noticias con fechas de publicación.
Estoy de acuerdo con su interpretación, Headbomb : incluso un periódico en línea con una fecha de publicación puede cambiar después de un tiempo, y esa documentación es muy defectuosa. - RexxS ( charla ) 22:31, 25 de agosto de 2020 (UTC)- Debería revisarse para cubrir el acceso en línea a las fuentes impresas . Un artículo del NY Times de 1993 puede tener una versión web, pero seguirá siendo estable, porque entonces el NY Time era una publicación impresa y no hay diferencia entre los dos. En 2020, cuando cita el NY Times , es probable que esté citando la versión web, que no es necesariamente estable como lo es la edición impresa. Headbomb { t · c · p · b } 22:39, 25 de agosto de 2020 (UTC)
- Headbomb , Incluso en la versión impresa del NY Times, habría varias ediciones impresas durante el día, y la cobertura se actualizaría para las noticias de última hora. Solía conseguir la primera edición del NY Times alrededor de las 10 de la noche la noche anterior a la fecha de publicación nominal. Sin embargo, supongo que eso terminó en 1997: https://www.nytimes.com/1997/08/02/nyregion/about-early-editions.html
- También hubo ediciones regionales; la versión vendida en la ciudad era ligeramente diferente de la vendida en Long Island, los suburbios de Nueva Jersey, etc. La conclusión es que simplemente citar una fecha y un número de página para el NY Times no es suficiente para localizar definitivamente un artículo impreso. También necesita saber qué edición. Supongo que esto fue igualmente cierto para otros artículos. Sospecho que la gran mayoría de las personas que citan artículos no lo hacen. - RoySmith (charla) 22:56, 25 de agosto de 2020 (UTC)
- Debería revisarse para cubrir el acceso en línea a las fuentes impresas . Un artículo del NY Times de 1993 puede tener una versión web, pero seguirá siendo estable, porque entonces el NY Time era una publicación impresa y no hay diferencia entre los dos. En 2020, cuando cita el NY Times , es probable que esté citando la versión web, que no es necesariamente estable como lo es la edición impresa. Headbomb { t · c · p · b } 22:39, 25 de agosto de 2020 (UTC)
- [ Un poco fuera del tema ] Curiosamente, la documentación de las reclamaciones de {{ Cite web }}
- Las fechas de acceso no son relevantes para artículos publicados en fechas específicas. Si accedió a doi : 10.1007 / lrr-2016-1 hace 2 años, si accede hoy, o accede a él en 2 años, siempre se le presentará la misma versión del documento. Las fechas de acceso son relevantes para los sitios web que pueden cambiar, como esta historia para NY Times . Si accede a él en tres días, es posible que no vea el mismo contenido que está viendo ahora. Headbomb { t · c · p · b } 20:30, 25 de agosto de 2020 (UTC)
- Entonces para eso
|edition=Evening/Morning
es, no|access-date=
. Headbomb { t · c · p · b } 22:57, 25 de agosto de 2020 (UTC)
- Entonces para eso
- Pregunta incorrecta: esta funcionalidad puede y debe obtenerse usando | doi-access = free y similar, en lugar de usar un parámetro de URL duplicado. No deben estar vinculados donde solo lleve al lector a un muro de pago, porque eso no los ayuda. Es incorrecto suponer que los enlaces a URL se han colocado deliberadamente; la mayoría de ellos son probablemente automáticos cuando las personas usan la URL para generar una cita. ( t · c ) buidhe 03:33, 13 de agosto de 2020 (UTC)
- Sí . El título, como el lugar más intuitivo para encontrarlo, es el lugar más importante para el enlace. Que otros parámetros también puedan vincular a la fuente no es una buena justificación para no tener el vínculo en el título. ¡Boing! dijo Zebedee ( charla ) 16:38, 17 de agosto de 2020 (UTC)
- Esta pregunta no significa nada, o la primera redacción significa lo contrario de la segunda (después de "en otras palabras"). "Vincular" y "completar un determinado parámetro" no son lo mismo. Descarta todas las respuestas anteriores. Nemo 11:04, 21 de agosto de 2020 (UTC)
- Sí , es apropiado vincular el título incluso si ese vínculo ya está presente en la lista de identificadores. Como lector prefiero hacer clic en un título que tener que saber cómo funcionan los identificadores bibliográficos para seleccionar el más adecuado. - Pintoch ( charla ) 11:34, 21 de agosto de 2020 (UTC)
- Sí , entre una selección de enlaces en la plantilla, el enlace del título puede, y probablemente debería, duplicar el más útil, o al menos el de WP: SAYWHEREYOUGOTIT . - Francis Schonken ( charla ) 04:28, 24 de agosto de 2020 (UTC)
- Sí . Vinculamos títulos como una práctica estándar, creo que sería confuso para el lector saber por qué algunos títulos están vinculados y otros no. Creo que el punto de Rexx a continuación sobre la enseñanza de habilidades informáticas también es relevante aquí. Me gusta el punto WP: SAYWHEREYOUGOTIT , creo que la URL en el título debería ser aquella de donde se obtuvo originalmente la fuente, incluso si eso va a duplicar cosas. CaptainEek edita Ho Cap'n! ⚓ 09:11, 24 de agosto de 2020 (UTC)
- Sí, siempre que el DOI, etc. lleve a un muro de pago, pero el texto está disponible de forma gratuita y legal en una URL, incluso si esa URL es una preimpresión, etc. Certes ( charla ) 10:31, 24 de agosto de 2020 (UTC)
- No, a menos que sea una copia completamente gratuita, que debe ser generada por un parámetro de plantilla. WP: SAYWHEREYOUGOTIT no se aplica correctamente aquí, ya que dice explícitamente "... no importa si lee el material utilizando un servicio en línea ..." AManWithNoPlan ( charla ) 20:41, 24 de agosto de 2020 (UTC)
- WP: SAYWHEREYOUGOTIT requiere que el editor agregue contenido de un recurso en línea como un resumen de PubMed para proporcionar un enlace al recurso que usaron. El enlace del título es el lugar obvio para eso. Sin embargo, aboga por eliminar esos enlaces de título en contra de la política. - RexxS ( charla ) 21:06, 24 de agosto de 2020 (UTC)
- Depende . Si el enlace proporcionado por
|url=
está apuntando a exactamente la misma página que uno de los enlaces derivados de los identificadores proporcionados, no es necesario duplicar ese enlace en|url=
. (Soy imparcial en cuanto a si los enlaces solamente resolver a exactamente la misma página de destino debe ser considerado como "iguales", así, ya que el comportamiento de los resolutores y redirectores puede cambiar con el tiempo, y puede ser bueno tener una alternativa enlace.) Para comodidad de los usuarios que no saben qué son los identificadores y nunca hacen clic en ellos, el título aún podría estar vinculado a esta página mediante el enlace automático (manual o automático basado en prioridades); sin embargo, es importante que los editores siempre tienen el control total si la plantilla debe proporcionar enlaces automáticos y, de ser así, qué identificador debe seleccionarse. Si se proporcionan|url=
o|title-link=
, siempre deben tener prioridad sobre los enlaces derivados de identificadores. Sin embargo, si la URL y el enlace del identificador apuntan al mismo sitio , pero no exactamente a la misma página (por ejemplo, si el enlace del identificador apunta a una metapágina y la URL al PDF real), estos enlaces no son de ninguna manera "igual", y el enlace proporcionado a través|url=
nunca debe considerarse "un duplicado", "redundante" o "equivalente" al enlace del identificador. Dado que algunos usuarios agrupan estas definiciones semánticamente, la redacción exacta es relevante aquí. - Matthiaspaul ( charla ) 20:43, 24 de agosto de 2020 (UTC)
- Siguiendo con mi comentario anterior, me gustaría agregar que incluso en los casos en que
|url=
sea un duplicado exacto de un enlace derivado de un identificador, considero que la eliminación de|url=
if también|archive-url=
es inapropiada . Algunos enlaces derivados de identificadores están destinados a ser semipermanentes, pero en última instancia también están sujetos a rotura de enlaces, por lo que es bueno mantener las versiones archivadas. Si alguien ha hecho un esfuerzo adicional para proporcionar una instantánea archivada para dicho enlace, deberíamos estar agradecidos por esta contribución en lugar de destruirla. Cambiaría de opinión sobre esto solo si nuestras plantillas de citas introdujeran medios para proporcionar archivos de enlaces para enlaces de identificadores también. - Matthiaspaul ( charla ) 13:25, 1 de septiembre de 2020 (UTC)
- Siguiendo con mi comentario anterior, me gustaría agregar que incluso en los casos en que
- Sí . La flecha después del título debe estar vinculada al sitio web en el parámetro Url incluso si se proporcionan otros identificadores únicos. Johannes Schade ( charla ) 16:17, 31 de agosto de 2020 (UTC)
Eliminación de enlaces
3. ¿En qué circunstancias se debe eliminar un enlace de título de una cita, por un humano o por un bot (en otras palabras, cuándo debe |url=
quedar en blanco)?
- Cuando es redundante para los identificadores , por plantilla: Cite los # identificadores de la revista , o cuando es un enlace de muro de pago que no agrega nada a los enlaces ya presentes, por ejemplo, un enlace de muro de pago de EBSCO no agrega nada de lo que ya proporciona un DOI. Headbomb { t · c · p · b } 01:48, 5 de agosto de 2020 (UTC)
- Si la URL vinculada al título NO pasa a texto completo gratuito y se repite en otro identificador, se puede eliminar. Aparte de eso, nadie (humano o bot) debería eliminar enlaces a texto completo gratuito, particularmente según WP: CITEVAR y la necesidad de proporcionar accesibilidad a los lectores. Sandy Georgia ( Discusión ) 01:52, 5 de agosto de 2020 (UTC)
- No cuando sea redundante para los identificadores por las razones de mi voto a la Pregunta 2 anterior. Nunca por un bot porque la URL probablemente fue colocada allí por un ser humano, quien decidió que este enlace era el mejor enlace para el lector. Un bot no debería anular esa decisión humana. (Nota: reemplazar URL muertas con URL activas o archivadas no es eliminar ni dejar en blanco | url = y, por lo tanto, podría hacerlo un bot.) Solo con una buena razón por parte de un humano : si es copyvio, si es un enlace muerto o si hay otra buena razón. Confío en que los humanos tomen estas decisiones caso por caso de una manera que un bot no puede. Me preocupa especialmente que las personas se tomen el tiempo de seleccionar cuidadosamente las URL a las que enlazar, y un bot las borrará en masa . (Lo cual es lo que llevó a que este bot fuera bloqueado en primer lugar, creo). ¡ Le v ! v ich 01:58, 5 de agosto de 2020 (UTC)
- No hay ninguna razón para tener ambos
|pmc=91234
y . Asimismo por tener ambos y . Tampoco hay problema para limpiar esta redundancia inútil por bot. Headbomb { t · c · p · b } 02:00, 5 de agosto de 2020 (UTC)|url=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC91234/
|pmid=91234
|url=https://pubmed.ncbi.nlm.nih.gov/91234
- La razón para tener ambos es lo que dije en mi voto! En el n. ° 2 anterior: para que siempre sea así "haz clic en el título, ve a la fuente", para que el lector no tenga que pensar en cuál de los múltiples enlaces es el el mejor para hacer clic. Y sé que ha dicho que deberíamos lograr eso eliminando el parámetro | url y, en su lugar, tener un parámetro | url en blanco "autocompletar" de manera efectiva con el | doi o lo que sea, pero no es así como funcionan las plantillas CS1, y el los mantenedores han dicho anteriormente que no es así como van a funcionar en el corto plazo. Así que hasta entonces ... ¡ Le v ! v ich 02:04, 5 de agosto de 2020 (UTC)
- Eso descuida tres cosas. 1) PMC ya enlaza automáticamente el título. 2) Un enlace PMID tomará el lugar de una versión gratuita del registro, como PMC, si está declarado en la URL, o uno que se pueda encontrar, pero que aún no se haya agregado. 3) Si hay un consenso para vincular siempre el título, pase lo que pase, eso puede suceder automáticamente y no es necesario tener la url pmid en el parámetro url cuando solo se puede generar a partir del parámetro pmid. Headbomb { t · c · p · b } 02:11, 5 de agosto de 2020 (UTC)
- Cuando
|pmc=
ya existe, y da como resultado la misma salida orientada al lector que|url=
con un enlace a la misma página de PubMed Central, eliminar la URL redundante entraría en conflicto con WP: COSMETICBOT . WhatamIdoing ( charla ) 15:12, 5 de agosto de 2020 (UTC)- La cosmética no evita las ediciones, si están sucediendo otras cosas. - Green C 15:18, 5 de agosto de 2020 (UTC)
- Sí, pero ese pequeño "si" agrega una capa de complejidad, tanto en la programación del bot como en todos los humanos que leemos los cambios innecesarios a través de diff. WhatamIdoing ( charla ) 23:14, 5 de agosto de 2020 (UTC)
- La cosmética no evita las ediciones, si están sucediendo otras cosas. - Green C 15:18, 5 de agosto de 2020 (UTC)
- Cuando
- Eso descuida tres cosas. 1) PMC ya enlaza automáticamente el título. 2) Un enlace PMID tomará el lugar de una versión gratuita del registro, como PMC, si está declarado en la URL, o uno que se pueda encontrar, pero que aún no se haya agregado. 3) Si hay un consenso para vincular siempre el título, pase lo que pase, eso puede suceder automáticamente y no es necesario tener la url pmid en el parámetro url cuando solo se puede generar a partir del parámetro pmid. Headbomb { t · c · p · b } 02:11, 5 de agosto de 2020 (UTC)
- La razón para tener ambos es lo que dije en mi voto! En el n. ° 2 anterior: para que siempre sea así "haz clic en el título, ve a la fuente", para que el lector no tenga que pensar en cuál de los múltiples enlaces es el el mejor para hacer clic. Y sé que ha dicho que deberíamos lograr eso eliminando el parámetro | url y, en su lugar, tener un parámetro | url en blanco "autocompletar" de manera efectiva con el | doi o lo que sea, pero no es así como funcionan las plantillas CS1, y el los mantenedores han dicho anteriormente que no es así como van a funcionar en el corto plazo. Así que hasta entonces ... ¡ Le v ! v ich 02:04, 5 de agosto de 2020 (UTC)
- No hay ninguna razón para tener ambos
- Lo que dijo Sandy. No entiendo muy bien lo que dice Headbomb sobre el enlace automático. Desde el punto de vista del usuario, quiero que los títulos de los artículos estén vinculados a la URL del artículo si está disponible gratuitamente, con la URL oficial del editor en lugar de la URL de PMC. No quiero que los usuarios tengan que hacer clic en enlaces que solo están disponibles en códigos (PMC / PMID / DOI) porque no todos lo entenderán y no es coherente con el funcionamiento de otras fuentes (periódicos, sitios web). enlazando en referencias. Cualquier URL en los códigos es una ventaja y no me importa si duplican el enlace en el título. - Charla de Colin ° 09:16, 5 de agosto de 2020 (UTC)
- Creo que Headbomb significa Help_talk: Citation_Style_1 # Auto-linked_titles_with_free_DOIs y Wikipedia: Village_pump_ (propuestas) # Auto-linked_titles_in_citations_of_works_with_free-to-read_DOIs . La plantilla CS1 | 2 vinculará automáticamente el título. - Green C 14:25, 5 de agosto de 2020 (UTC)
- El principio rector debe ser que las URL se pueden romper y siempre se prefieren los parámetros. Las URL que deberían representarse más correctamente mediante parámetros deben moverse del campo URL y traducirse al parámetro correcto. Si el parámetro correcto ya está presente, la URL redundante debe eliminarse. La URL también debe eliminarse para facilitar la violación de los derechos de autor, aunque no estoy seguro de que los bots puedan administrarla. - Chris Capoccia 💬 12:12, 5 de agosto de 2020 (UTC)
- No debe eliminarse si la URL es para texto libre ... haya o no un enlace de identificador y si ese enlace de identificador es redundante o no. - Ealdgyth ( charla ) 13:43, 5 de agosto de 2020 (UTC)
- ¿Qué pasa con los "enlaces de título redundantes enlazados automáticamente"? - Green C 15:18, 5 de agosto de 2020 (UTC)
- El título de la cita siempre debe vincular a la fuente en línea más útil . La única razón para eliminar un enlace de título es cuando apunta a una infracción de derechos de autor. Esa es una decisión que solo puede tomar (y debatir) un ser humano. Un bot nunca debe hacer una edición que tenga como resultado para los lectores eliminar un enlace del título de una cita. - RexxS ( charla ) 14:31, 5 de agosto de 2020 (UTC)
- No tiene sentido tener ambos
|pmid=91234
y solo por el bien de preservar un enlace. O enlaces redundantes a recursos de pago. Headbomb { t · c · p · b } 14:36, 5 de agosto de 2020 (UTC)|url=https://pubmed.ncbi.nlm.nih.gov/91234
- Pero, ¿tiene algún sentido inundar las listas de seguimiento de todos para eliminar la URL? WhatamIdoing ( charla ) 15:14, 5 de agosto de 2020 (UTC)
- Entonces, la URL codificada muere o cambia. Es trivial arreglar el enlace automático en el cfg central CS1 | 2. Pero, IABot detectará la URL estática muerta en la cita individual y agregará una URL de archivo. Ahora tenemos una cita que no se enlaza correctamente porque hay una URL muerta en el
|url=
campo que tiene prioridad, con una innecesaria|archiveurl=
que probablemente debería eliminarse junto con la URL estática. O, podemos eliminar de forma proactiva la URL redundante para evitar un desastre en el futuro. - Verde |url=debe completar). # 093;"> C 15:28 , 5 de agosto de 2020 (UTC)- O podríamos asumir que los escenarios basados en PubMed Central (parte de los Institutos Nacionales de Salud de EE. UU . ) Que se desconectan, o que no pueden encontrar sus propios documentos cuando se les dan sus propios números de identificación, simplemente no son muy convincentes. WhatamIdoing ( charla ) 23:20, 5 de agosto de 2020 (UTC)
- Entonces, la URL codificada muere o cambia. Es trivial arreglar el enlace automático en el cfg central CS1 | 2. Pero, IABot detectará la URL estática muerta en la cita individual y agregará una URL de archivo. Ahora tenemos una cita que no se enlaza correctamente porque hay una URL muerta en el
- Tiene mucho sentido tener un enlace desde el título, y no debería haber un bot que lo elimine. A nadie le importan los detalles de la implementación, excepto a un grupo de tecno-geeks. El lector es lo primero y no les importa qué parámetros tenemos en el wikitexto, solo quieren hacer clic en el título para llegar a una fuente, y un bot nunca debería estar haciendo una edición que elimine eso de ellos. - RexxS ( charla ) 16:35, 5 de agosto de 2020 (UTC)
- Si es tan trivial arreglar el enlace automático, ¿por qué no se ha hecho después de tres meses? Incluso entonces, la URL codificada de forma rígida puede ser necesaria cuando una fuente gratuita de acceso directo no está vinculada desde ningún identificador. También es necesario permitir que una URL archivada se vincule directamente desde el título de la cita, que los bots parecen incapaces de resolver, una solución mucho mejor que eliminar los enlaces de forma preventiva en caso de que se conviertan en enlaces muertos. - RexxS ( charla ) 16:35, 5 de agosto de 2020 (UTC)
- Porque las actualizaciones de CS1 dependen básicamente de que Usuario: Trapense, el monje, decida que es hora de hacer una actualización. En teoría, no es una limitación, pero necesita conocer LUA y ser administrador para actualizar los módulos CS1 / 2. Pero esto no es algo particularmente difícil de hacer para aquellos con las habilidades. Headbomb { t · c · p · b } 18:06, 8 de agosto de 2020 (UTC)
- Ah, pero RexxS hace saber Lua, y es un administrador - de hecho, cuando tengo un problema lua, prefiero ir a RexxS y no trapense. - Red rose64 🌹 ( charla ) 19:44, 8 de agosto de 2020 (UTC)
- Sin embargo, Trappist ha realizado un gran esfuerzo para crear y mantener los módulos CS1 / 2. Eso significa que Trappist tiene una visión general mucho mejor de las complejidades y características de ese módulo que yo. No me sentiría cómodo editando ninguno de esos módulos, principalmente porque automáticamente le diría al responsable de mantenimiento de un módulo que lo sepa mejor que yo. Lo mismo se aplicaría, por ejemplo, con los módulos de conversión de Johnuniq . - RexxS ( conversación ) 20:55, 8 de agosto de 2020 (UTC)
- Ah, pero RexxS hace saber Lua, y es un administrador - de hecho, cuando tengo un problema lua, prefiero ir a RexxS y no trapense. - Red rose64 🌹 ( charla ) 19:44, 8 de agosto de 2020 (UTC)
- Porque las actualizaciones de CS1 dependen básicamente de que Usuario: Trapense, el monje, decida que es hora de hacer una actualización. En teoría, no es una limitación, pero necesita conocer LUA y ser administrador para actualizar los módulos CS1 / 2. Pero esto no es algo particularmente difícil de hacer para aquellos con las habilidades. Headbomb { t · c · p · b } 18:06, 8 de agosto de 2020 (UTC)
- ¿Puede verificar si se trata de un enlace automático?
- Hoffman SJ; Lavis JN; Bennett S. (2009). "El uso de la evidencia de la investigación en las recomendaciones de dos organizaciones internacionales sobre sistemas de salud" . Política sanitaria . 5 (1): 66–86. doi : 10.12927 / hcpol.2009.21005 .
- En este ejemplo, sería redundante agregarlo porque es la misma URL que ya se generó; casi todos están de acuerdo con esto. En términos de archivos, es poco probable que doi.org muera por completo en lugar de cambiar su sintaxis de URL (la URL base) que se puede "arreglar" fácilmente en la plantilla cfg, de la misma manera que podríamos hacerlo con plantillas de enlaces externos como si alguna vez cambiaran de base URLs. Si muriera por completo, probablemente cambiaríamos a un proveedor de ID diferente como el enlace automático predeterminado. Actualmente, los bot no archivan las URL de ID en este momento, pero dada la incertidumbre, deberían esperar para determinar el resultado, y no hay ninguna razón técnica por la que no puedan hacerlo. Por cierto, mi formación profesional es Historia. Sospecho que eres más techno friki que yo. Pero no lo tengo en tu contra :) Mi interés son las humanidades y la tecnología que lo hace más accesible para un público más amplio. - Green C 20:35, 5 de agosto de 2020 (UTC)
|url=https://doi.org/10.12927/hcpol.2009.21005
{{gutenberg author}}
- @ GreenC : Puedo verificar que la cita que cita está vinculando el título, pero dudo seriamente que haya algo automático al respecto. Lo apreciaras
- Hoffman SJ; Lavis JN; Bennett S. (2009). "El uso de la evidencia de la investigación en las recomendaciones de dos organizaciones internacionales sobre sistemas de salud" . Política sanitaria . 5 (1): 66–86. PMC 2732656 .
- también tiene el título vinculado. ¿Eso hace que el doi sea redundante? Todos vinculan el título a la fuente, entonces, ¿jugar con ellos realmente beneficia al lector?
- ¿Qué pasa con estas citas? ¿Por qué cambiaríamos el primero por el segundo?
- Coulter DA, Huguenard JR, Prince DA (junio de 1989). "Caracterización de la reducción de etosuximida de la corriente de calcio de umbral bajo en neuronas talámicas" . Annals of Neurology . 25 (6): 582–93. doi : 10.1002 / ana.410250610 . PMID 2545161 .
- Coulter DA, Huguenard JR, Prince DA (junio de 1989). "Caracterización de la reducción de etosuximida de la corriente de calcio de umbral bajo en neuronas talámicas". Annals of Neurology . 25 (6): 582–93. doi : 10.1002 / ana.410250610 . PMID 2545161 . S2CID 20670160 .
- ¿Cómo benefició esta edición al lector?
- FWIW, mi primer título fue en ingeniería electrónica, pero eso fue en 1972 y no había geeks en esos días. :( - RexxS ( charla ) 22:15, 5 de agosto de 2020 (UTC)
- El
|pmc=2732656
indica a la plantilla que genere automáticamente una URL de título . Cuál es mi comprensión de la vinculación automática. El ID|pmc=2732656
y generar el mismo enlace de título, por lo tanto, son redundantes, ¿mantenemos ambos de todos modos? Tiene razón en que debemos no cambie la primera a la segunda, ya que eliminaría el enlace del título con un nuevo enlace está generando. Bueno, eres como una generación, tengo 92 '... eran nerds cuando significaba algo. - Green C 23:56, 5 de agosto de 2020 (UTC)|url=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2732656
- @ RexxS : La edición que cuestionó, eliminando un enlace directo a Semantic Scholar y reemplazándolo por una identificación S2CID, beneficia al lector al no engañarlo haciéndole pensar que puede seguir el enlace para encontrar la referencia real, cuando en realidad solo lo hará encontrar una página de destino allí que les diga que deberían haber seguido el DOI en su lugar. - David Eppstein ( charla ) 06:47, 6 de agosto de 2020 (UTC)
- @ David Eppstein : eliminar un enlace a una versión de la fuente (que luego los llevará a una versión completa) y reemplazarlo con nada no beneficia al lector. La mayoría de los lectores no comprenden s2cid o doi, por lo que los editores no deberían obligarlos a adaptarse a su forma preferida de trabajar. ¿Cuándo se darán cuenta de que el cambio necesario en esa edición era vincular el título a un sitio mejor para mejorarlo, no eliminarlo por completo y empeorarlo? - RexxS ( charla ) 16:24, 6 de agosto de 2020 (UTC)
- Cuando dice que reemplazar un enlace en el título a un enlace en el S2CID es eliminar el enlace por completo, creo que está exagerando ridículamente el problema. Y cuando dice que los lectores son incapaces de comprender los enlaces descritos como identificadores y solo son capaces de encontrar y seguir enlaces cuando esos enlaces se colocan en el título de una referencia, creo que está subestimando enormemente la competencia de los lectores. - David Eppstein ( charla ) 19:01, 6 de agosto de 2020 (UTC)
- Y creo que su personalización de los problemas genuinos resta valor a la gravedad de los problemas. La eliminación de un enlace del título de una cita no debería suceder porque los lectores esperan que el enlace esté allí. Estás intentando dejar de lado el problema como si no importara. Bueno, lo hace. Del mismo modo, no está demostrando ninguna comprensión de las dificultades que experimentan los lectores comunes al tratar de dar sentido a una plétora de acrónimos y símbolos diferentes. No todo el mundo está tan dotado técnicamente como tú y sobrestimas la disposición de un lector (que solo quiere ver una fuente) para aprender una jerga diseñada para ser utilizada por académicos que la utilizan a diario. - RexxS ( conversación ) 21:51, 6 de agosto de 2020 (UTC)
- No se trata de aprender jerga. Se trata de ser capaz de notar que algo en la referencia está enlazado y ver a dónde vas cuando sigues ese enlace. Si no puede hacer eso, tampoco puede usar Wikipedia, usar la web o seguir los enlaces en los títulos. - David Eppstein ( charla ) 01:12, 7 de agosto de 2020 (UTC)
- Si hubiera pasado tantos años como yo enseñando a adultos, especialmente a aquellos de mi edad, habilidades informáticas básicas, pronto revisaría su "
ser capaz de notar que algo en la referencia está vinculado y ver a dónde vas cuando sigues ese vínculo. Si no puede hacer eso, tampoco puede usar Wikipedia, usar la web o seguir los enlaces en los títulos.
Dar a la gente vías predecibles, como "hacer clic en un título le lleva a la fuente" es precisamente la forma en que pueden utilizar Wikipedia, utilizar la web y seguir los enlaces en los títulos. - RexxS ( charla ) 16:49, 8 de agosto de 2020 (UTC)
- Si hubiera pasado tantos años como yo enseñando a adultos, especialmente a aquellos de mi edad, habilidades informáticas básicas, pronto revisaría su "
- No se trata de aprender jerga. Se trata de ser capaz de notar que algo en la referencia está enlazado y ver a dónde vas cuando sigues ese enlace. Si no puede hacer eso, tampoco puede usar Wikipedia, usar la web o seguir los enlaces en los títulos. - David Eppstein ( charla ) 01:12, 7 de agosto de 2020 (UTC)
- Y creo que su personalización de los problemas genuinos resta valor a la gravedad de los problemas. La eliminación de un enlace del título de una cita no debería suceder porque los lectores esperan que el enlace esté allí. Estás intentando dejar de lado el problema como si no importara. Bueno, lo hace. Del mismo modo, no está demostrando ninguna comprensión de las dificultades que experimentan los lectores comunes al tratar de dar sentido a una plétora de acrónimos y símbolos diferentes. No todo el mundo está tan dotado técnicamente como tú y sobrestimas la disposición de un lector (que solo quiere ver una fuente) para aprender una jerga diseñada para ser utilizada por académicos que la utilizan a diario. - RexxS ( conversación ) 21:51, 6 de agosto de 2020 (UTC)
- Cuando dice que reemplazar un enlace en el título a un enlace en el S2CID es eliminar el enlace por completo, creo que está exagerando ridículamente el problema. Y cuando dice que los lectores son incapaces de comprender los enlaces descritos como identificadores y solo son capaces de encontrar y seguir enlaces cuando esos enlaces se colocan en el título de una referencia, creo que está subestimando enormemente la competencia de los lectores. - David Eppstein ( charla ) 19:01, 6 de agosto de 2020 (UTC)
- @ David Eppstein : eliminar un enlace a una versión de la fuente (que luego los llevará a una versión completa) y reemplazarlo con nada no beneficia al lector. La mayoría de los lectores no comprenden s2cid o doi, por lo que los editores no deberían obligarlos a adaptarse a su forma preferida de trabajar. ¿Cuándo se darán cuenta de que el cambio necesario en esa edición era vincular el título a un sitio mejor para mejorarlo, no eliminarlo por completo y empeorarlo? - RexxS ( charla ) 16:24, 6 de agosto de 2020 (UTC)
- @ RexxS : La edición que cuestionó, eliminando un enlace directo a Semantic Scholar y reemplazándolo por una identificación S2CID, beneficia al lector al no engañarlo haciéndole pensar que puede seguir el enlace para encontrar la referencia real, cuando en realidad solo lo hará encontrar una página de destino allí que les diga que deberían haber seguido el DOI en su lugar. - David Eppstein ( charla ) 06:47, 6 de agosto de 2020 (UTC)
- El
- @ GreenC : Puedo verificar que la cita que cita está vinculando el título, pero dudo seriamente que haya algo automático al respecto. Lo apreciaras
- Si es tan trivial arreglar el enlace automático, ¿por qué no se ha hecho después de tres meses? Incluso entonces, la URL codificada de forma rígida puede ser necesaria cuando una fuente gratuita de acceso directo no está vinculada desde ningún identificador. También es necesario permitir que una URL archivada se vincule directamente desde el título de la cita, que los bots parecen incapaces de resolver, una solución mucho mejor que eliminar los enlaces de forma preventiva en caso de que se conviertan en enlaces muertos. - RexxS ( charla ) 16:35, 5 de agosto de 2020 (UTC)
- Pero, ¿tiene algún sentido inundar las listas de seguimiento de todos para eliminar la URL? WhatamIdoing ( charla ) 15:14, 5 de agosto de 2020 (UTC)
- No tiene sentido tener ambos
- Eliminar según Chris Capoccia y Headbomb, si la plantilla CS1 | 2 ya está vinculando automáticamente el campo del título (según el consenso de RfC y las discusiones en curso en Help_talk: Citation_Style_1) no hay ninguna razón o propósito lógico para tener una URL redundante en el
|url=
campo. Si la URL no es redundante, es decir. que son diferentes URL, debe no ser retirados desde la|url=
es una anulación manual de la autolink. - Green C 14:37, 5 de agosto de 2020 (UTC) - Solo por un humano, y solo con el propósito de hacer que el estilo de la cita dentro de un artículo sea consistente con su estado anterior, según WP: CITEVAR . - David Eppstein ( charla ) 06:41, 6 de agosto de 2020 (UTC)
- El bot no debería , y un humano solo debería hacerlo para elegir conscientemente un enlace mejor / más apropiado, no porque sea redundante. C Thomas 3 ( charla ) 20:52, 6 de agosto de 2020 (UTC)
- Solo elimine el enlace si se dirige a un sitio obsoleto (por ejemplo, si viola los derechos de autor o si está muerto) o si es incorrecto. No se moleste en quitarlo solo por PMC o DOI o similares. Eso es simplemente abarrotar las listas de seguimiento sin ningún beneficio. Por supuesto, los otros parámetros se pueden agregar incluso si hay un enlace en el título. Graeme Bartlett ( charla ) 12:07, 7 de agosto de 2020 (UTC)
- Prohibir bots No podemos tener bots administrados por editores SEO pagados que luchan por insertar sus enlaces preferidos. Según WP: CITEVAR , el problema debe dejarse a discreción del editor humano que realmente utilizó la fuente en cuestión para respaldar parte del texto del artículo. Andrew 🐉 ( charla ) 12:11, 7 de agosto de 2020 (UTC)
- Si no está roto, no lo arregles. · · · Peter Southwood (charla) : 15:18, 7 de agosto de 2020 (UTC)
- Para aclarar: no creo que esté roto y no creo que sea necesario arreglarlo. Si la URL del enlace del título funciona, déjela en paz. · · · Peter Southwood (charla) : 10:57, 9 de agosto de 2020 (UTC)
- Está roto. Arreglemoslo. Cualquier título vinculado de forma redundante debe
|url=
eliminarse . La wikipedia está sobrevinculada tal como está. Un enlace redundante es un enlace de más. —¿Philoserf? ( charla ) 08:36, 8 de agosto de 2020 (UTC) - El enlace del título nunca debe eliminarse, incluso si es redundante. Si, y solo si, la plantilla / módulo generará este enlace automáticamente en función de otros parámetros,
|url=
se puede establecer en blanco o, mejor, en un comentario HTML que explique por qué, pero no de otra manera. Todo esto asumiendo que el artículo usa CS1 o CS @, por supuesto. DES (charla) DESiegel Contribs 01:08, 12 de agosto de 2020 (UTC) - Nunca por un bot Los bots no deberían estar cuestionando las decisiones tomadas por humanos reales. Apoyaría a un bot que identifica los casos que necesitan atención humana, pero nunca hace este tipo de cambios por sí mismos. - Charla de Nick Thorne 23:54, 13 de agosto de 2020 (UTC)
- Según RexxS anterior, el título de la cita siempre debe vincular a la fuente en línea más útil (salvo copyvio). No sé si puede haber casos en los que haya un buen argumento para no tener el enlace (a diferencia de Holmes, no pretendo poder eliminar todas las posibilidades). Pero si lo hay, entonces debe ser decidido por un humano. El enlace nunca debe ser eliminado por un bot. ¡Boing! dijo Zebedee ( hablar ) 16:44, 17 de agosto de 2020 (UTC)
- No cambie , a diferencia de que existe un acceso de código abierto al documento completo, pero ese es el propósito de OABOT , por lo que tal vez lo permita en casos precisos, pero no para generalizar a todos. La política principal es no eliminar la información útil que ya está presente. El objetivo de los bots en el mantenimiento de citas es ayudar a los wikipedistas a agregar información y automatizar la búsqueda de información, para asegurarse de que la cita sea más precisa y accesible. Voilà, voilà. - Anas1712 ( charla ) 14:42, 18 de agosto de 2020 (UTC)
- No elimine los enlaces de título sobre la base de que duplican identificadores. Está bien eliminar un
|url=
si la plantilla generará el mismo enlace en el título mediante el enlace automático, pero no de otra manera. - Pintoch ( charla ) 11:37, 21 de agosto de 2020 (UTC)- También está más que bien eliminar enlaces que conducen a bases de datos sin posibilidad de versiones gratuitas (como pubmed), a documentos de pago (como EBSCO y proxies), a preprints (como arxiv). Headbomb { t · c · p · b } 15:27, 22 de agosto de 2020 (UTC)
- No está bien eliminar el enlace donde el editor encontró su fuente por WP: SAYWHEREYOUGOTIT . Si encontraron su información en un artículo de resumen de PubMed, deberíamos darle al editor la capacidad de indicarlo a través del enlace del título, y deberíamos darle al lector la oportunidad de seguir el enlace intuitivo a la fuente utilizada para escribir el texto. No deberíamos dejar que un robot caprichoso los lleve a la basura. - RexxS ( charla ) 21:03, 24 de agosto de 2020 (UTC)
- También está más que bien eliminar enlaces que conducen a bases de datos sin posibilidad de versiones gratuitas (como pubmed), a documentos de pago (como EBSCO y proxies), a preprints (como arxiv). Headbomb { t · c · p · b } 15:27, 22 de agosto de 2020 (UTC)
- El contenido de
|url=
debe decidirse caso por caso, por editores humanos, no modificado por bot; un bot es bienvenido para abordar enlaces mal formados, enlaces permanentemente inactivos, etc., pero no debe modificar la intención de los editores humanos. - Francis Schonken ( charla ) 04:28, 24 de agosto de 2020 (UTC) - Nunca por bot y muy raramente por humano, no puedo pensar en una buena razón para que un bot elimine el parámetro de URL. No puedo pensar en una razón más allá de la violación de los derechos de autor para que un humano elimine la URL, aunque supongo que debe haber alguna razón por la que no he soñado :) En general, el punto de Rexx sobre tener títulos vinculados consistentemente me gana, y por lo tanto Creo que esta es una buena razón para mantener los títulos vinculados. Los humanos siempre pueden usar su mejor criterio para averiguar si un enlace debe funcionar, pero no veo la necesidad de que CitationBot lo haga. CaptainEek edita Ho Cap'n! ⚓ 09:17 , 24 de agosto de 2020 (UTC)
- Cuando es redundante para los identificadores La vinculación a copias no gratuitas con el título genera confusión en el lector cuando esperan que el vínculo del título se vincule realmente a algo útil. No puedo creer que no me di cuenta de que esta discusión estaba sucediendo hasta ahora. AManWithNoPlan ( conversación ) 20:44, 24 de agosto de 2020 (UTC)
- Los identificadores son inferiores a los enlaces de título porque los lectores comprenden y esperan enlaces de título. Su bot se complace en eliminar los enlaces de título que van a las URL de pmc. Ese tipo de enlaces, los que utiliza el editor para agregar texto, son enlaces de título útiles, y ningún lector se confundirá si se le permite seguir ese tipo de enlaces. - RexxS ( charla ) 21:03, 24 de agosto de 2020 (UTC)
- Solo cuando sea idéntico a otros enlaces . No hay punto de mantener un
|url=
enlace si se apunta a exactamente la misma página como un identificador de enlace derivados. Este es el único caso en el que|url=
se justifica la eliminación (automática) de (excepto si apunta a contenido ilegal que siempre justifica su eliminación), y este es también el único caso para el que realmente tuvimos consenso de la comunidad. Si|url=
resuelve a exactamente la misma página,|url=
pueden ser removidos por un ser humano después de aplicar criterio editorial, pero no deben ser retirados por un bot, porque un robot no puede aplicar el criterio editorial es necesario, si el resolutor, con alta certidumbre, determinación de la misma página en el futuro a largo plazo, o si puede cambiar con el tiempo. Un enlace que apunta solo al mismo sitio (como enlaces al documento directo frente a una metapágina) no es "igual" y, por lo tanto, nunca debe considerarse "redundante", "equivalente", "duplicado", etc., y en consecuencia, no debe eliminarse. (Dado que algunos usuarios agrupan estas definiciones semánticamente, la redacción exacta es importante). Además,|url=
señalar un recurso no libre o de acceso restringido nunca es una razón válida para eliminar un enlace según nuestra política central sobre verificabilidad WP: V y el principio de WP: SAYWHEREYOUGOTIT . Por esa razón, tampoco se|url=
debe quitar (sino|url-status=dead
fijar) un muerto , ya que esto invalidaría la citación. Por supuesto, si es posible reemplazar un enlace (muerto) por una URL de autoría similar o mejor en vivo, eso está permitido para humanos (y en algunos casos muy limitados también puede estar permitido para algunos bots de gran prestigio; sin embargo, no para Citation Bot, que tiene un largo historial de estropear las citas y a lo largo de los años ha creado demasiado daño al proyecto para que aún tenga credibilidad, en mi opinión: la calidad de las ediciones es mucho más importante que la cantidad). - Matthiaspaul ( charla ) 21:39, 24 de agosto de 2020 (UTC)
- Me gustaría agregar que incluso en los casos en que
|url=
sea un duplicado exacto de un enlace derivado de un identificador, no se deben eliminar si también|archive-url=
se proporcionan (a menos que las plantillas de citas introduzcan parámetros para especificar enlaces de archivo para identificadores también). Algunos enlaces derivados de identificadores están destinados a ser semipermanentes, pero en última instancia también están sujetos a rotura de enlaces, por lo que es bueno mantener las versiones archivadas. - Matthiaspaul ( charla ) 13:31, 1 de septiembre de 2020 (UTC)
- Me gustaría agregar que incluso en los casos en que
- El bot nunca ; un humano podría estar justificado para hacerlo en raras circunstancias especiales. Johannes Schade ( charla ) 16:26, 31 de agosto de 2020 (UTC)
- Matthiaspaul dice arriba
Para comodidad de los usuarios que no saben qué son los identificadores y nunca hacen clic en ellos, el título aún podría estar vinculado a esta página a través de un enlace automático (manual o automático basado en prioridades).
Creo que en tales casos eliminar|url=
está bien; el parámetro se libera para alguna otra URL potencial y, mientras tanto, los lectores no ven ningún cambio, ya que el título todavía tiene la URL derivada de ID de enlace automático. Por supuesto, el resumen de edición debería proporcionar [un enlace a] una explicación tranquilizadora de esto. jnestorius ( charla ) 14:13, 3 de septiembre de 2020 (UTC)
- Sí, en caso de que esto no quede claro en mi publicación anterior, si
|url=
apunta exactamente a la misma página que se proporciona a través de un enlace de identificación y no hay|archive-url=
, entonces|url=
no tiene ningún propósito y puede liberarse para mejores usos. (Con|archive-url=
estar presente, no estaría de acuerdo con la eliminación de a|url=
menos que las plantillas de citas se mejoren para admitir enlaces de archivo para enlaces de identificador también). Lo que también es un problema es que Citation Bot ha sido detectado para eliminar|url=
también en los casos en que el identificador- los enlaces derivados no eran idénticos, sino que solo apuntaban al mismo sitio (metapágina frente a enlace profundo al documento) o incluso a un sitio completamente diferente que por casualidad contenía información similar. Esto es algo que considero perturbador e inaceptable. Es por eso que señalé que la gente tiene ideas muy diferentes sobre lo que significan términos como "duplicado", "equivalente" o "redundante" y que, por lo tanto, deben usarse los términos inequívocos "idéntico" o "igual". - Matthiaspaul ( charla ) 15:34, 3 de septiembre de 2020 (UTC)
- Sí, en caso de que esto no quede claro en mi publicación anterior, si
- Necesitamos una mejor plantilla CS1 / CS2, si los enlaces de título son importantes , creo que cuando no hay ningún enlace de título presente, la plantilla siempre debería intentar crear uno. Si algo libre no está configurado, entonces auto-vincule doi asumiendo que no es gratis en los íconos. Pienso en Wikipedia sobre los enlaces, pero si vamos a insistir en los enlaces, hagamos que aparezcan por arte de magia. AManWithNoPlan ( charla ) 14:27, 3 de septiembre de 2020 (UTC)
Sincronización de descripciones breves y descripciones de Wikidata
- La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.
¿Debería un bot sincronizar descripciones breves y descripciones de Wikidata? Mike Peel ( charla ) 21:34, 6 de agosto de 2020 (UTC)
Hola todos. Enwp obtuvo recientemente 'descripciones breves', que es una " explicación concisa del alcance de la página " (para el contexto, consulte los enlaces en Wikipedia: Descripción breve # Historia ). Actualmente, se trata de una anulación local para las descripciones en inglés de Wikidata para 2,3 millones de artículos (1/3 de los artículos aquí), pero esto puede cambiar pronto para que solo se usen las descripciones locales (eliminándolas de 2/3 de los artículos). . Creo que es importante que las descripciones breves y las descripciones de Wikidata se mantengan lo más sincronizadas posible. Esto se debe tanto a que las descripciones son más visibles en enwp como a que las descripciones de Wikidata en inglés se utilizan en muchos otros lugares, en particular (desde mi punto de vista) en los infoboxes de las categorías de Wikimedia Commons. Como tal, propongo cuatro opciones para que las tareas de bot las sincronicen, a saber:
- En Wikidata, opción D1 : si no hay una descripción en inglés de Wikidata, entonces importe la descripción breve de Wikipedia en inglés
- En Wikidata, opción D2 : si Wikidata tiene una descripción en inglés, pero no coincide con las descripciones breves de Wikipedia en inglés, reemplace la descripción de Wikidata con la descripción breve enwp
- Aquí, opción E1 : Si no hay una descripción breve aquí, entonces importe la descripción en inglés de Wikidata.
- Aquí, opción E2 : Si la descripción breve aquí no coincide con Wikidata, reemplace la descripción breve aquí con la de Wikidata.
Comencé una discusión en Wikidata sobre los dos primeros , en la que puedes participar. También hay discusiones en ambas páginas de propuestas de bots. Inicialmente comencé un hilo aquí en Wikipedia_talk: Short_description # Copying_short_descriptions_to_Wikidata , pero las discusiones sobre Wikidata llevaron a la propuesta del bot aquí, y la discusión allí a su vez sugirió un RfC. Afirmo que estas descripciones son demasiado cortas para ser elegibles para derechos de autor (lo que podría ser un problema ya que usamos CC-BY-SA aquí pero CC-0 en Wikidata). He enviado un correo electrónico a WMF legal para confirmar esto.
Sé que esta es una discusión controvertida: este hilo, y el hilo que comencé en Wikidata, tienen como objetivo iniciar discusiones sobre cómo mantenemos las cosas sincronizadas. Estoy codificando abiertamente para subir otros scripts de bots entre wiki si es necesario. Creo que lo mejor para ambos proyectos es trabajar juntos. ¿Qué piensas? Gracias. Mike Peel ( charla ) 21:34, 6 de agosto de 2020 (UTC)
Encuesta
- Apoyaría D1 y E1 ya que solo están importando lo que está disponible. D2 y E2 podrían resultar en el reemplazo de una mejor descripción, por lo que sería necesaria una solución para evitarlo. Emir de Wikipedia ( charla ) 21:38, 6 de agosto de 2020 (UTC) ( responda, gracias!)
{{reply to}}
- @ Emir de Wikipedia : ¿Hay alguna manera de saber automáticamente cuál es mejor, o se necesitaría un humano para verificarlo? Gracias. Mike Peel ( charla ) 21:48, 6 de agosto de 2020 (UTC)
- Mejor es algo subjetivo, por lo que probablemente tendría que ser humano. Emir de Wikipedia ( charla ) 21:52, 6 de agosto de 2020 (UTC)
- @ Emir de Wikipedia : ¿Hay alguna manera de saber automáticamente cuál es mejor, o se necesitaría un humano para verificarlo? Gracias. Mike Peel ( charla ) 21:48, 6 de agosto de 2020 (UTC)
- Soporta D1 y E1; oponerse a D2 y E2 . Copiar para llenar espacios vacíos está bien, pero la sobrescritura automática es una receta para conflictos feroces. - Brown HairedGirl (charla) • ( contribuciones ) 21:46, 6 de agosto de 2020 (UTC)
- Comente sobre D1 y D2 : estas son decisiones de contenido de Wikidata para que las decida la comunidad de Wikidata. ¿La comunidad de Wikidata ha delegado su autoridad de toma de decisiones con respecto a las descripciones de Wikidata en inglés a la Wikipedia en inglés? - Jonesey95 ( charla ) 21:57, 6 de agosto de 2020 (UTC)
- De hecho, es por eso que dije: "Comencé una discusión en Wikidata sobre los dos primeros , en los que puedes participar". Gracias. Mike Peel ( charla ) 11:20, 7 de agosto de 2020 (UTC)
- Soporte parcial de E1 : algunas de las descripciones están mal redactadas y otras son demasiado largas para cumplir con nuestras pautas. Apoyaría la importación de un conjunto limitado de descripciones breves para ciertas categorías de artículos, como especies de animales / plantas y futbolistas, donde las descripciones pueden verificarse para determinar la longitud adecuada y compararse con la pertenencia a la categoría aquí en en.WP. Oponerse a E2 , porque las descripciones breves locales suelen ser mejores que las de Wikidata, como se ha demostrado en la discusión de Wikidata vinculada anteriormente. - Jonesey95 ( charla ) 21:57, 6 de agosto de 2020 (UTC)
- Jonesey95 , ¿Tiene alguna sugerencia sobre cómo identificar descripciones breves aceptables de Wikidata para este propósito? Podría ser una opción útil si es lo suficientemente confiable. Saludos, · · · Peter Southwood (charla) : 10:47, 7 de agosto de 2020 (UTC)
- He rellenado varios miles de descripciones breves y algunas categorías de artículos parecen ser bastante consistentes en su calidad. Los deportistas de diversos tipos tienden a tener descripciones breves fiables, al igual que los fósiles, por ejemplo. Un humano podría identificar una categoría principal en Wikipedia como Categoría: jugadores de fútbol de la asociación , o profundizar en una subcategoría como Categoría: futbolistas ingleses (22.000 artículos). Dentro de esas categorías, excluya los artículos que ya tengan una descripción breve, luego ejecute un informe que muestre la descripción de Wikidata para cada artículo. Un humano podría ver un informe de 1000 artículos a la vez, eliminar manualmente las páginas con descripciones incorrectas de Wikidata y realizar una importación por lotes del resto. No sería un proceso de bot automatizado, pero creo que una vez que haya configurado el sistema, será rápido procesar muchos miles de artículos por hora. Puede preguntar en la página del proyecto por categorías probables. Solo en futbolistas, probablemente podrías agregar más de 100,000 descripciones breves en un par de días. El mismo proceso podría usarse para especies, libros, películas y otros elementos en los que el bot de Wikidata que creó las descripciones tuvo un tiempo fácil para procesar la oración principal (o cualquier información que usara). - Jonesey95 ( charla ) 16:02, 7 de agosto de 2020 (UTC)
- Jonesey95 Eso lo haría semiautomatizado, en el sentido de que habría un editor asumiendo la responsabilidad de verificar el lote. Apoyo eso en principio. · · · Peter Southwood (charla) : 08:01, 28 de agosto de 2020 (UTC)
- He rellenado varios miles de descripciones breves y algunas categorías de artículos parecen ser bastante consistentes en su calidad. Los deportistas de diversos tipos tienden a tener descripciones breves fiables, al igual que los fósiles, por ejemplo. Un humano podría identificar una categoría principal en Wikipedia como Categoría: jugadores de fútbol de la asociación , o profundizar en una subcategoría como Categoría: futbolistas ingleses (22.000 artículos). Dentro de esas categorías, excluya los artículos que ya tengan una descripción breve, luego ejecute un informe que muestre la descripción de Wikidata para cada artículo. Un humano podría ver un informe de 1000 artículos a la vez, eliminar manualmente las páginas con descripciones incorrectas de Wikidata y realizar una importación por lotes del resto. No sería un proceso de bot automatizado, pero creo que una vez que haya configurado el sistema, será rápido procesar muchos miles de artículos por hora. Puede preguntar en la página del proyecto por categorías probables. Solo en futbolistas, probablemente podrías agregar más de 100,000 descripciones breves en un par de días. El mismo proceso podría usarse para especies, libros, películas y otros elementos en los que el bot de Wikidata que creó las descripciones tuvo un tiempo fácil para procesar la oración principal (o cualquier información que usara). - Jonesey95 ( charla ) 16:02, 7 de agosto de 2020 (UTC)
- Jonesey95 , ¿Tiene alguna sugerencia sobre cómo identificar descripciones breves aceptables de Wikidata para este propósito? Podría ser una opción útil si es lo suficientemente confiable. Saludos, · · · Peter Southwood (charla) : 10:47, 7 de agosto de 2020 (UTC)
- Soporte parcial . D1 y D2 son asunto de Wikidata; si estuviera más involucrado allí, apoyaría D1 pero tengo reservas sobre D2. E1 es bueno en principio pero corre el riesgo de importar descripciones vandalizadas o específicas de Wikidata (ejemplo inventado: "concepto filosófico; para el verbo use Q12345 en su lugar"). Oponerse a E2, pero quizás deberíamos informar casos en alguna parte. ¿Tiene valor mantener una lista / categoría / lo que sea de descripciones que difieran deliberadamente entre enwiki y Wikidata, y reducir el tamaño de D2 / E2 para "encontrar e informar diferencias que no estén en esa lista"? Certes ( charla ) 22:14, 6 de agosto de 2020 (UTC)
- Alguien está un paso por delante de mí. Ver también Categoría: La descripción breve es diferente de Wikidata , Módulo: SDcat y WT: Descripción breve # Agregar categorías de seguimiento . Certes ( charla ) 23:23, 6 de agosto de 2020 (UTC)
- Si adoptamos E1, para algunas o todas las páginas, deberíamos etiquetar las descripciones importadas (categoría oculta: ¿Descripción corta importada de Wikidata?), Para que podamos revisarlas gradualmente, mejorar si es necesario y luego eliminar la etiqueta. Certes ( charla ) 11:08, 11 de agosto de 2020 (UTC)
- Fuerte oposición a E2 , ya que anula el punto de la introducción de {{ breve descripción }} por completo. * Pppery * ha comenzado ... 22:37, 6 de agosto de 2020 (UTC)
- @ Pppery : ¿Cómo sugeriría que resolvamos esas diferencias? Gracias. Mike Peel ( charla ) 23:01, 6 de agosto de 2020 (UTC)
- Se podría usar una categoría de seguimiento para encontrar artículos con descripciones breves diferentes de las descripciones breves de Wikidata. Los editores podrían usar Shortdesc Helper para importar (con o sin modificaciones, según las pautas de WP) o exportar (con el consentimiento de la comunidad de Wikidata) la mejor descripción. - Jonesey95 ( charla ) 23:20, 6 de agosto de 2020 (UTC)
- @ Pppery : ¿Cómo sugeriría que resolvamos esas diferencias? Gracias. Mike Peel ( charla ) 23:01, 6 de agosto de 2020 (UTC)
- He dividido mis votos! En líneas separadas para facilitar el recuento para el vendedor:
- Fuerte soporte D1, E1 como mejoras obvias. Podemos eliminar descripciones redundantes como "Artículo de lista" una vez que el enlace de Wikidata esté desactivado.
- Soporte débil D2 porque es más probable que enwiki tenga una mejor descripción que wikidata, ya que hay muchos más editores activos y muchos menos artículos / elementos en enwiki que en wikidata.
- Débil oponente E2 por la razón anterior. Estos son débiles, porque reconozco que habrá muchas excepciones al caso general, y se necesitará algo de cuidado para implementar cualquier sobrescritura. - RexxS ( conversación ) 22:57, 6 de agosto de 2020 (UTC)
- @ RexxS : ¿Cómo propondría que resolvamos las diferencias entre enwp y Wikidata en los casos de D2 y E2? Gracias. Mike Peel ( charla ) 23:00, 6 de agosto de 2020 (UTC)
- @ Mike : Haga un corto plazo si alguno de los dos obtiene consenso, luego analice cada uno de esos reemplazos manualmente. Espere un par de días para recibir reacciones y críticas. Si no está tan mal, enjuague y repita un par de veces antes de cualquier trabajo a gran escala. - RexxS ( charla ) 23:07, 6 de agosto de 2020 (UTC)
- @ RexxS : Me complace hacer tiradas cortas y resolver cualquier problema que surja . Mi principal preocupación es la ausencia de consenso. Gracias. Mike Peel ( charla ) 23:40, 6 de agosto de 2020 (UTC)
- @ Mike : Haga un corto plazo si alguno de los dos obtiene consenso, luego analice cada uno de esos reemplazos manualmente. Espere un par de días para recibir reacciones y críticas. Si no está tan mal, enjuague y repita un par de veces antes de cualquier trabajo a gran escala. - RexxS ( charla ) 23:07, 6 de agosto de 2020 (UTC)
- Comentario : ¿el resultado de un Rfc en-wiki tiene alguna relación con lo que Wikidata decide hacer? Puedo escuchar la voz de Lydia diciendo: "No sucederá". Este Rfc puede no tener sentido. Mathglot ( charla ) 23:16, 6 de agosto de 2020 (UTC)
- @ Mathglot : Creo que te perdiste que hay discusiones paralelas sobre Wikidata y enwp. Si no podemos trabajar juntos, estamos jodidos. Gracias. Mike Peel ( charla ) 23:44, 6 de agosto de 2020 (UTC)
- Meh ... Ha habido una clara falta de cooperación entre los dos proyectos durante un tiempo. Ambos parecen estar bien. No creo que ninguno de los dos esté jodido. Blueboar ( charla ) 00:17, 7 de agosto de 2020 (UTC)
- WP: NODEADLINE. Estaremos. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 16:38, 8 de agosto de 2020 (UTC)
- Meh ... Ha habido una clara falta de cooperación entre los dos proyectos durante un tiempo. Ambos parecen estar bien. No creo que ninguno de los dos esté jodido. Blueboar ( charla ) 00:17, 7 de agosto de 2020 (UTC)
- @ Mathglot : Creo que te perdiste que hay discusiones paralelas sobre Wikidata y enwp. Si no podemos trabajar juntos, estamos jodidos. Gracias. Mike Peel ( charla ) 23:44, 6 de agosto de 2020 (UTC)
- Wikidata y Wikipedia.en son proyectos separados y NO NECESITAN estar sincronizados. Idealmente, apoyaría el E3: no prestamos atención a Wikidata y escribimos nuestras propias descripciones breves. Sin embargo, me doy cuenta de que esto requeriría mucha mano de obra, por lo que (a regañadientes) aceptaría E-1, siempre y cuando podamos enmendar posteriormente cualquier descripción si así lo deseamos. Me opondría a E-2. Blueboar ( charla ) 23:36, 6 de agosto de 2020 (UTC)
- Este es el statu quo durante los últimos años. No requiere mucha mano de obra, ya que la mayoría de las personas probablemente aún no los conocen y no tienen la herramienta que los hace fáciles. Cambiarlos en cualquier momento también es fácil con el dispositivo. Hacer que el dispositivo sea predeterminado probablemente aceleraría bastante el proceso. · · · Peter Southwood (charla) : 13:54, 7 de agosto de 2020 (UTC)
- Oponerse : El error original fue que alguien asumió que las descripciones de los artículos de Wikidata y las descripciones de los artículos de EnWiki eran (o deberían ser) iguales o intercambiables. Las descripciones de artículos de Wikidata y las descripciones de artículos de EnWiki tienen diferentes propósitos y bajo diferentes políticas. Wikidata puede y debe tener descripciones que no pertenecen aquí, y podemos y debemos tener descripciones que no pertenecen allí. Sería perjudicial presionar a cualquiera de las comunidades para que hicieran lo mismo. (La importación de descripciones de Wikidata puede haber sido aceptable como parte de un proceso y limpieza de una sola vez si las descripciones de Wikidata se hubieran cerrado de inmediato, pero obviamente eso no sucedió).
- D1 - Fuera de alcance . Es un asunto interno de la comunidad de Wikidata.
- D1 - Fuera de alcance . Es un asunto interno de la comunidad de Wikidata.
- E1 - Oponerse :
- Un bot no debe sobrescribir (o potencialmente editar war) descripciones en blanco deliberadamente.
- El gadget auxiliar de descripción corta hace que sea trivialmente fácil importar descripciones de Wikidata, después de que la revisión humana considera que la versión de Wikidata es apropiada para los propósitos de Enwiki y según las políticas y pautas locales, y lo consideran una mejora. No deberíamos importar cosas sin tener en cuenta si pertenecen aquí o no.
- E2 - Difícil oposición . Tendría más sentido proponer revertir el sistema local por completo, volviendo a la visualización automática de descripciones de Wikidata. Alerta de spoiler: Eso no obtendrá consenso. Hubo un consenso abrumador para eliminar el sistema original de mostrar descripciones de Wikidata aquí. Alsee ( charla ) 01:56, 7 de agosto de 2020 (UTC)
- No existe tal cosa como "una descripción deliberadamente en blanco". Cuando falta la descripción corta o está vacía, el software proporciona el valor de Wikidata, que está fuera de nuestro control. Si importamos el valor de Wikidata en una descripción breve previamente en blanco, no perderíamos nada y obtendríamos la capacidad de editar la descripción breve para que se ajuste a nuestras políticas y protegerla con nuestras medidas antivandálicas. - RexxS ( charla ) 16:53, 7 de agosto de 2020 (UTC)
- Oponerse a cualquier edición de bot, especialmente E2. Si a Wikidata le gustaría importar descripciones de EnWP, por mí está bien, y lo apoyaría, pero realmente depende de la gente de WikiData. Pero no creo que debamos importar descripciones de Wikdata. Si usa la herramienta shortDescription, ya puede hacerlo, y las descripciones de WikiData casi siempre son basura generada por una máquina. Son muy rápidos de hacer y agrego una breve descripción a cada artículo que visito. La mayoría no tiene descripciones de WikiData cuando creo nuevas descripciones de todos modos. En mi opinión, E2 es muy problemático: facilitaría el vandalismo de descripciones breves, provocaría guerras de edición y no sería bueno en general. CaptainEek edita Ho Cap'n! ⚓ 05:55, 7 de agosto de 2020 (UTC)
- Gracias Mike Peel por plantear esto como una discusión, pero tengo que estar de acuerdo con Alsee en que D1 y D2 están fuera del alcance de la comunidad en-WP para decidir, y E1 y E2 deberían oponerse como (lamentablemente) una invitación demasiado abierta para inexactitudes y vandalismo crosswiki. Las adiciones de Shortdesc están progresando bien en en-WP, dejemos que continúe en su forma actual. - Euryalus ( charla ) 06:02, 7 de agosto de 2020 (UTC)
- Apoye firmemente la sincronización como concepto general. Las descripciones de Wikidata y las descripciones breves en-WP son fundamentalmente lo mismo: descripciones breves. ¿Hay casos ocasionales en los que puedan divergir adecuadamente? Seguro. Pero, ¿significa eso que deberían estar totalmente divididos, lo que probablemente lleve a miles de horas de esfuerzo del editor duplicado (es decir, desperdiciado) para crear lo mismo en dos lugares separados? Absolutamente no.
- Es importante conectar esto con el panorama general aquí. El éxito del movimiento Wikimedia se basa fundamentalmente en tener suficientes personas para hacer el trabajo. Esa es la razón principal por la que eliminamos las páginas que no son notables. Siempre que elegimos bifurcar, eso literalmente duplica la cantidad de trabajo por hacer, que cuando se multiplica por 6 millones, resulta en un costo gigantesco en el esfuerzo del editor. Por lo tanto, la prevención de las bifurcaciones debe ser una de nuestras principales prioridades. Peor aún, una vez que se ha hecho una bifurcación, la reintegración se vuelve cada vez más difícil con el tiempo. Reconozco que hay muchos desafíos para hacerlo aquí, tanto por las razones iniciales de la bifurcación como por los obstáculos de la divergencia hasta ahora, pero a un nivel fundamental, ese es el camino en el que debemos estar.
- Con respecto a las propuestas específicas, D1 y D2 son decisiones que debe tomar Wikidata, no nosotros, por lo que están fuera de alcance. E1 puede tener sentido, y E2 definitivamente no tiene sentido, ya que donde divergen, las descripciones en-WP tienden a ser mejores (debido a la mayor base de usuarios). Creo que lo que probablemente sucederá es que Wikidata en algún momento reconocerá (quizás ahora, quizás en unos años) que las descripciones en-WP son mejores y buscará adoptarlas. La pregunta entonces es cómo manejar las situaciones en las que se supone que son diferentes. Se necesita un poco más de discusión en Wikidata para definir cuáles son exactamente esas circunstancias y la mejor manera de manejarlas (probablemente mediante alguna modificación técnica, de modo que, por ejemplo, "para el verbo use Q12345 en su lugar" se pueda agregar al resumen de en-WP descripción). {{u | Sdkb }} charla 07:21, 7 de agosto de 2020 (UTC)
- Este sería un buen punto si se pudiera demostrar que las descripciones de Wikidata y las descripciones breves de Wiikipedia tienen, de hecho, una coincidencia suficientemente cercana en los usos. En Wikipedia tenemos una idea razonablemente buena de cuáles son los usos de las descripciones breves, y podemos expandirlas cuando queramos, pero ¿dónde se define en Wikidata? También hay bastante claramente una serie de tipos de casos en los que "sin descripción breve" sería lo más apropiado en Wikipedia. Puede que esto no sea cierto para Wikidata. Tenga en cuenta que en Wikidata ni siquiera es posible proporcionar una referencia para la descripción. En Wikipedia podemos usar el artículo como fuente, y si lo consideramos necesario o deseable, podemos hacer una forma de agregar una referencia.
- Dado que se consideran contenido en Wikpedia, el lugar adecuado para ellos es Wikipedia, donde los wikipedistas pueden crearlos y mantenerlos. Si no tiene sentido la duplicación, translúdalos a Wikidata. Entonces tampoco pueden ser vandalizados en Wikidata (2 problemas resueltos: no duplicar y más ojos en el contenido).
- En el panorama general, los proyectos independientes del movimiento Wikipedia tienden a encajar mucho mejor cuando se deja a la comunidad de cada proyecto decidir qué contenido de otros proyectos eligen usar. Tratar de convencerlos de que deben usar el contenido de otro proyecto porque el otro proyecto cree que es mejor a menudo se encuentra con una resistencia obstinada y una selección de buenas razones por las que no funcionaría, en las que los proponentes no pensaron, porque no lo hacen. tienen que lidiar con los problemas que no ven como problemas. Saludos, · · · Peter Southwood (charla) : 13:36, 7 de agosto de 2020 (UTC)
- Oponerse a E1 : por ejemplo, para páginas de desambiguación, enwiki puede decidir que no se necesita una descripción breve (si la página ya tiene "desambiguación" o algo similar en el título), mientras que Wikidata tendrá "página de desambiguación de Wikimedia" como descripción breve. Importar esto sería contraproducente. En primer lugar, se opone firmemente a que E2 no entienda por qué todo este esfuerzo se ha realizado. Si quisiéramos que nuestras descripciones fueran las mismas que las de Wikidata, no nos habríamos molestado con la "descripción breve" en primer lugar. Como se ha dicho, D1 y D2 están completamente fuera del alcance de una discusión aquí (al igual que E1 y E2 estarían fuera del alcance de una discusión en Wikidata). Fram ( charla ) 07:28, 7 de agosto de 2020 (UTC)
- Es bastante fácil evitar páginas que usan {{ Desambiguación }} si lo desea. Gracias. Mike Peel ( charla ) 11:20, 7 de agosto de 2020 (UTC)
- Sí, las páginas de desambiguación necesitan una descripción corta estándar o ninguna. Son especiales porque describen su título más que uno de sus posibles significados. Venus necesita algo para decirle al lector que se trata de un planeta en lugar de una deidad o una almeja . Mercurio se trata de "mercurio" en todos sus sentidos. Certes ( charla ) 11:32, 7 de agosto de 2020 (UTC)
- No importa si enwiki decide que ciertos artículos no deben tener una descripción corta, porque el software no lo permite. La elección actual es entre una descripción tomada automáticamente de Wikidata donde no tenemos control sobre ella, o crear una descripción en enwiki que podamos editar para que se ajuste a nuestras políticas y protegernos contra el vandalismo. - RexxS ( charla ) 16:53, 7 de agosto de 2020 (UTC)
- El software no lo permite sin embargo : la WMF prometió que desactivar esta opción cuando llegamos a la marca de los 2 millones, pero "sorpresa" es que tienen algo no se ha hecho realidad para lograr esto y han estado "trabajando en ello" hace meses . Pero si y cuando la WMF hace lo que prometió, entonces una descripción breve "en blanco" en enwiki será perfectamente posible técnicamente. Fram ( charla ) 17:19, 7 de agosto de 2020 (UTC)
- Jam mañana. Pero esto es ahora . Si y cuando WMF apague las descripciones breves de Wikidata de enwiki, será un simple trabajo de bot eliminar todas las descripciones repetitivas inútiles como "Artículo de lista", incluidas las que importamos desde Wikidata hoy. Pero mientras tanto, tenemos el control y la patrulla antivandálica sobre los que hemos puesto aquí, en lugar de depender de Wikidata para controlar esta parte de nuestro contenido. - RexxS ( conversación ) 11:45, 10 de agosto de 2020 (UTC)
- No tengo idea de lo que quieres decir con "Jam mañana". En todo caso; con E1, importamos todas las descripciones de Wikidata (que se muestran ahora de todos modos, por lo que ahora no hay mejoras ) y luego nos quedamos atrapados con esa importación masiva sin supervisión cuando WMF mantiene su promesa de desactivar las descripciones de Wikidata. Básicamente, E1 es una forma de deshacer el RfC de la comunidad en las descripciones de Wikidata para los millones de artículos que aún no tienen una descripción corta (suponiendo que tengan una en Wikidata, que a menudo tampoco es el caso). Entonces podríamos haber copiado fácilmente las descripciones en primer lugar; pero la comunidad decidió no hacerlo debido a problemas de calidad. Estos problemas de calidad no han desaparecido mágicamente mientras tanto, por lo que no hay razón para importarlos ahora de todos modos. Es mejor no tener descripciones que importar a ciegas las de Wikidata; y mejores buenas descripciones que ninguna descripción. Fram ( charla ) 15:31, 10 de agosto de 2020 (UTC)
- "Jam tomorrow" es una frase del diálogo de Alice con la Reina Blanca. Creo que encontrarás la conversación citada en nuestro artículo Jam de mañana que recuerda inquietantemente nuestras interacciones con los equipos de WMF. Puedo simpatizar con su posición si puedo convencerme de que llegará un mañana cuando las descripciones de Wikidata estén realmente apagadas, pero ya nos han mordido así una vez . - RexxS ( conversación ) 15:51, 10 de agosto de 2020 (UTC)
La regla es, mermelada mañana y mermelada ayer, pero nunca jam hoy.
- Lewis Carroll, A través del espejo y lo que Alicia encontró allí , capítulo V . - Red rose64 🌹 ( charla ) 16:46, 10 de agosto de 2020 (UTC)- Gracias a ambos. Fram ( charla ) 10:09, 11 de agosto de 2020 (UTC)
- No tengo idea de lo que quieres decir con "Jam mañana". En todo caso; con E1, importamos todas las descripciones de Wikidata (que se muestran ahora de todos modos, por lo que ahora no hay mejoras ) y luego nos quedamos atrapados con esa importación masiva sin supervisión cuando WMF mantiene su promesa de desactivar las descripciones de Wikidata. Básicamente, E1 es una forma de deshacer el RfC de la comunidad en las descripciones de Wikidata para los millones de artículos que aún no tienen una descripción corta (suponiendo que tengan una en Wikidata, que a menudo tampoco es el caso). Entonces podríamos haber copiado fácilmente las descripciones en primer lugar; pero la comunidad decidió no hacerlo debido a problemas de calidad. Estos problemas de calidad no han desaparecido mágicamente mientras tanto, por lo que no hay razón para importarlos ahora de todos modos. Es mejor no tener descripciones que importar a ciegas las de Wikidata; y mejores buenas descripciones que ninguna descripción. Fram ( charla ) 15:31, 10 de agosto de 2020 (UTC)
- Jam mañana. Pero esto es ahora . Si y cuando WMF apague las descripciones breves de Wikidata de enwiki, será un simple trabajo de bot eliminar todas las descripciones repetitivas inútiles como "Artículo de lista", incluidas las que importamos desde Wikidata hoy. Pero mientras tanto, tenemos el control y la patrulla antivandálica sobre los que hemos puesto aquí, en lugar de depender de Wikidata para controlar esta parte de nuestro contenido. - RexxS ( conversación ) 11:45, 10 de agosto de 2020 (UTC)
- El software no lo permite sin embargo : la WMF prometió que desactivar esta opción cuando llegamos a la marca de los 2 millones, pero "sorpresa" es que tienen algo no se ha hecho realidad para lograr esto y han estado "trabajando en ello" hace meses . Pero si y cuando la WMF hace lo que prometió, entonces una descripción breve "en blanco" en enwiki será perfectamente posible técnicamente. Fram ( charla ) 17:19, 7 de agosto de 2020 (UTC)
- Oponerse a E1 / E2 - E1, porque muchas veces, especialmente con títulos naturalmente descriptivos que no pueden mejorarse o describirse mejor brevemente, lo que desea es vacío. Y también en parte por las razones dadas por Alsee (y Fram). Asimismo, E2, por la génesis y la razón de ser de las descripciones breves (y por A & F). Mathglot ( charla ) 09:15, 7 de agosto de 2020 (UTC)
- Oponerse a E1 como una acción de bot. Todas las importaciones de descripciones breves de Wikidata quedan a discreción de un editor en vivo, quien será responsable de que sean apropiadas. Varias importaciones inapropiadas pueden provocar un bloqueo. Ya existe un consenso significativo para este ítem en en: WP. · · · Peter Southwood (charla) : 09:37, 7 de agosto de 2020 (UTC)
- Oponerse a E2 Existe un consenso bastante amplio y de larga data sobre este punto que no parece probable que cambie aquí. Esta sería una ofensa bloqueable. · · · Peter Southwood (charla) : 09:37, 7 de agosto de 2020 (UTC)
- Comente sobre D1 y D2 No nuestro circo, no nuestros monos. Esto es algo para tratar con la comunidad de Wikidata, está fuera de nuestra competencia decidir. Pueden hacerlo si así lo desean. · · · Peter Southwood (charla) : 09:37, 7 de agosto de 2020 (UTC)
- He notificado a Wikipedia: WikiProject Breves descripciones en su página de discusión . Cualquiera puede sentirse bienvenido para verificar y asegurarse de que la notificación tenga un tono adecuadamente neutral. Saludos, · · · Peter Southwood (charla) : 09:58, 7 de agosto de 2020 (UTC)
- D1 y D2 están fuera del alcance de un enwiki RfC, por lo que no los comentaré aquí (entiendo que hay una discusión sobre wikidata, pero esto es solo para cubrir esto en aras de la integridad)
- Fuerte oposición a E2, ya que esta es esencialmente la situación que teníamos antes de {{ breve descripción }} pero con ediciones de bot adicionales. Si la comunidad cree que esto está bien, entonces seguramente seguiremos usando las descripciones de wikidata. No he analizado completamente los beneficios / desventajas del uso de wikidata para descripciones breves, por lo que esta oposición se basa en la idea de que tener un bot de importación periódica no es una idea tan buena en comparación con la sincronización automática del lado del servidor (que es lo que tenía antes).
- Oponerse a E1. Si la comunidad tiene problemas porque las descripciones breves son inexactas o si las etiquetas no siempre son una buena idea para las descripciones breves, la importación masiva sería perjudicial. Además, es probable que una proporción sea incorrecta o necesite mejorar. El script de usuario que importa descripciones breves parece estar haciendo un buen trabajo cubriendo el problema, haciendo que un editor verifique la descripción breve antes de importarla. Dreamy Jazz habla conmigo | mis contribuciones 11:39, 7 de agosto de 2020 (UTC)
- Oponerse a la importación a Wikipedia en inglés, ya que muchas descripciones breves en Wikidata son demasiado genéricas y no son útiles. Para las importaciones de Wikidata, por favor discútalo allí. Graeme Bartlett ( charla ) 12:11, 7 de agosto de 2020 (UTC)
- Comente sobre la alternativa a E1: escriba nuestro propio bot. Casi
seis3,7 millones de artículos de Wikipedia no tienen una descripción breve, y deberían. Para ellos, sería mejor, como último recurso, tomar los textos de los bots de Wikidata que esperar que los editores aquí arreglen esa cantidad de artículos manualmente en un tiempo razonable. Pero esas no son las únicas opciones. Alguien llenó los textos de Wikidata usando un bot bastante simple, y no hay ninguna razón por la que la comunidad de Wikipedia aquí no pueda hacer lo mismo, pero con más sofisticación. Ya hay un grupo activo de editores trabajando en descripciones breves de WikiProject , y se ha solicitado ayuda de bot (por mí y por otros). Con un compromiso adecuado de un escritor de bots capacitado, estoy seguro de que habrá suficientes ojos para garantizar un alto nivel tanto de confiabilidad como de utilidad para nuestros propósitos. Se necesita una gran cantidad de tiempo para editar y verificar cada SD nuevo manualmente si el artículo tiene que abrirse cada vez, pero si un escritor de bot pudiera proporcionar borradores de textos en un formato de tabla para revisión manual antes de actualizar, el esfuerzo manual sería muy largo. menos. Yo, y estoy seguro de que muchos otros, estaríamos encantados de ayudar con las especificaciones técnicas de un bot de este tipo, aunque no puedo hacer la codificación real. MichaelMaggs ( charla ) 13:07, 7 de agosto de 2020 (UTC)- Ver también: PearBOT 5 . Certes ( charla ) 13:58, 7 de agosto de 2020 (UTC)
- @ MichaelMaggs : En principio, podría ayudar con esto, ya que puedo codificar y operar scripts pywikibot (que es lo que inició toda esta discusión). Sin embargo, no estoy seguro de que haya consenso para hacer esto, dados los comentarios anti-bot en esta discusión. Tal vez pueda redactar especificaciones que crea que obtendrán consenso, yo puedo codificar algo y podemos agregar una opción adicional a esta discusión para ver si estaría bien (o iniciar otra discusión). Gracias. Mike Peel ( charla ) 19:15, 7 de agosto de 2020 (UTC)
- @ Mike Peel : Gracias Mike, sería de gran ayuda. No creo que haya serias objeciones a la generación automática de nuevas SD completamente desde Wikipedia, ya que eso ya lo han hecho de forma esporádica varios editores de WikiProject Short descriptions , y de hecho se recomienda allí; las objeciones anteriores se refieren más a la importación de descripciones de Wikidata de mala calidad. He expuesto más detalles de una propuesta en la charla de Wikipedia: WikiProject Descripciones cortas # Miniproyecto para generar nuevas descripciones cortas por categoría . MichaelMaggs ( charla ) 10:17, 8 de agosto de 2020 (UTC)
- @ MichaelMaggs : En principio, podría ayudar con esto, ya que puedo codificar y operar scripts pywikibot (que es lo que inició toda esta discusión). Sin embargo, no estoy seguro de que haya consenso para hacer esto, dados los comentarios anti-bot en esta discusión. Tal vez pueda redactar especificaciones que crea que obtendrán consenso, yo puedo codificar algo y podemos agregar una opción adicional a esta discusión para ver si estaría bien (o iniciar otra discusión). Gracias. Mike Peel ( charla ) 19:15, 7 de agosto de 2020 (UTC)
- Ver también: PearBOT 5 . Certes ( charla ) 13:58, 7 de agosto de 2020 (UTC)
- Oponerse a E1 y E2 (los únicos que tenemos que decidir aquí en la Wikipedia en inglés, lo que hace Wikidata es su propia decisión que debe tomarse en su propio proyecto) según Alsee. ¿Y no nos decidimos ya por E1 y E2 en el pasado, entonces, por qué estamos haciendo esto de nuevo? - Ealdgyth ( charla ) 13:13, 7 de agosto de 2020 (UTC)
- Oponerse firmemente al E2. Con respecto a E1, Dreamy Jazz escribió (arriba), "El script de usuario que importa descripciones breves parece estar haciendo un buen trabajo cubriendo el problema, haciendo que un editor verifique la descripción breve antes de importarla". - Estoy de acuerdo. Por lo tanto, me opongo a E1 si significa un bot autónomo que completa breves descripciones de Wikidata. - Mark D Worthen PsyD (hablar) (Soy un hombre, los pronombres masculinos tradicionales están bien) 00:16, 8 de agosto de 2020 (UTC)
- El script es una buena herramienta, pero funcionaría mejor si lo usaran más personas. Hacer que lo utilicen requiere que sepan que existe y que se necesitan descripciones breves. No todo el mundo se preocupa o está interesado. Creo que son útiles cuando tienen una calidad razonable y, en su mayoría, vale la pena el esfuerzo, pero no todos comparten este punto de vista. · · · Peter Southwood (charla) : 08:18, 8 de agosto de 2020 (UTC)
- Soporta D1 y E1; Me opongo firmemente a D2 y E2 : en mi experiencia, queremos control de contenido aquí. He encontrado graffiti y cosas peores en wikidata. Haga de este wiki la autoridad e importe lo que tiene wikidata para que podamos corregirlo. —¿Philoserf? ( charla ) 08:27, 8 de agosto de 2020 (UTC)
- D1 y D2 no son para que los abordemos aquí. Opónganse a E1 por necesitar una definición más clara. Oponerse firmemente a E2 por ser lo opuesto al consenso y desharía mucho progreso. - GhostInTheMachine me habla a las 15:24, 8 de agosto de 2020 (UTC)
- Apoye a E1, oponga a E2 , Wikidata puede hacer lo que quiera con respecto a D1 y D2. Realmente estoy bien con la sincronización en cualquier dirección, pero en los casos en que los datos existen en ambos lugares, los datos locales siempre deben anular los remotos; de lo contrario, existe una enorme vulnerabilidad a la interrupción remota que no podemos usar herramientas locales para prevenir. Ivanvector ( Talk / ediciones ) 14:29 10 de Agosto de 2020 (UTC)
- Lamento cuestionarlo, pero ¿realmente quiso oponerse al E1? Ese es el caso donde Wikipedia en inglés no tiene una descripción local (por lo que el software usa la descripción remota de Wikidata de todos modos). ¿Importar esa descripción remota al menos facilitaría la edición aquí y reduciría la posibilidad de que sea vandalizada? - Comentario anterior sin firmar agregado por RexxS ( charla • contribuciones ) 15:11, 10 de agosto de 2020 (UTC)
- Si he entendido correctamente, eso es cierto solo hasta que se produzca el cambio prometido. Posteriormente, E1 nos mueve de ninguna descripción a una descripción importada a ciegas que se puede editar o eliminar. Eso no es obviamente malo, pero es diferente. Certes ( charla ) 15:50, 10 de agosto de 2020 (UTC)
- Disculpas si he entendido mal las opciones. Si ya no hay una descripción aquí, importar la descripción de Wikidata debería ser inofensivo, es lo que los usuarios ven de todos modos. Mi única opinión muy fuerte es que si no es una descripción aquí, Wikidata no debe reescribir. Ivanvector ( Talk / ediciones ) doce y diecisiete, 11 de Octubre 2020 (UTC)
- @ Ivanvector : Lo que describe es neutral en D1 / D2, soporte para E1 (si no hay una descripción breve aquí, entonces importe la descripción en inglés de Wikidata) y oponga a E2 (si la descripción breve aquí no coincide con Wikidata, luego reemplace la breve descripción aquí con la de Wikidata.) - Red rose64 🌹 ( charla ) 09:15, 11 de agosto de 2020 (UTC)
- Sí, tienes razón, mi error. Cambié mi comentario. Ivanvector ( Talk / ediciones ) 10:00, 11 de Octubre 2020 (UTC)
- @ Ivanvector : Lo que describe es neutral en D1 / D2, soporte para E1 (si no hay una descripción breve aquí, entonces importe la descripción en inglés de Wikidata) y oponga a E2 (si la descripción breve aquí no coincide con Wikidata, luego reemplace la breve descripción aquí con la de Wikidata.) - Red rose64 🌹 ( charla ) 09:15, 11 de agosto de 2020 (UTC)
- Disculpas si he entendido mal las opciones. Si ya no hay una descripción aquí, importar la descripción de Wikidata debería ser inofensivo, es lo que los usuarios ven de todos modos. Mi única opinión muy fuerte es que si no es una descripción aquí, Wikidata no debe reescribir. Ivanvector ( Talk / ediciones ) doce y diecisiete, 11 de Octubre 2020 (UTC)
- Si he entendido correctamente, eso es cierto solo hasta que se produzca el cambio prometido. Posteriormente, E1 nos mueve de ninguna descripción a una descripción importada a ciegas que se puede editar o eliminar. Eso no es obviamente malo, pero es diferente. Certes ( charla ) 15:50, 10 de agosto de 2020 (UTC)
- Lamento cuestionarlo, pero ¿realmente quiso oponerse al E1? Ese es el caso donde Wikipedia en inglés no tiene una descripción local (por lo que el software usa la descripción remota de Wikidata de todos modos). ¿Importar esa descripción remota al menos facilitaría la edición aquí y reduciría la posibilidad de que sea vandalizada? - Comentario anterior sin firmar agregado por RexxS ( charla • contribuciones ) 15:11, 10 de agosto de 2020 (UTC)
- Oponerse firmemente a E1 y E2 . Hasta que Wikidata tenga una verificación mucho mejor, no quiero que nada de Wikidata se importe a los artículos EN. DES (charla) DESiegel Contribs 01:17, 12 de agosto de 2020 (UTC)
- Apoye a E1 , oponga a E2 . No hay opinión sobre D1 y D2, que dependen de la comunidad de Wikidata. Veo comentarios como el de DESiegel de arriba sobre no querer nada de Wikidata, y simpatizo, pero en la práctica ya está sucediendo ya que en los casos que caen bajo E1 estamos mostrando el texto de Wikidata. Lo que haría E1 es hacer visible inmediatamente el vandalismo a la descripción en las listas de seguimiento aquí, y eso es una gran ventaja. También significa que podemos dejar de preocuparnos por el vandalismo en Wikidata, ya que no tendría ningún efecto aquí. E2 no tiene sentido a la luz de las decisiones anteriores de la comunidad de que la breve descripción aquí anule lo que esté en Wikidata. Mike Christie ( charla - contribuciones - biblioteca ) 18:19, 13 de agosto de 2020 (UTC)
- Mike Christie, usted hace un punto válido de que una vez que las descripciones de Wikidata se copian en WP, cualquier vandalismo en Wikidata se vuelve irrelevante y podemos mejorarlas aquí, pero hasta que eso esté hecho, son nuestra responsabilidad para BLP, etc. ¿Quién sería responsable? ¿El propietario del bot? ¿La persona que autoriza la ejecución del bot? Además, ¿alguien sabe cuántas de las SD sobresalientes todavía tienen una versión de Wikidata disponible para copiar? Supongo que sería del orden de un millón, pero podría perder mucho. · · · Peter Southwood (charla) : 14:26, 28 de agosto de 2020 (UTC)
- Bueno, dime si me equivoco, pero cualquier cosa que consideremos vandalismo ya está apareciendo, ¿verdad? Por ejemplo, si un BLP tiene una breve descripción de "criminal convicto" en Wikidata, lo estamos viendo en la búsqueda móvil ahora, pero no podemos detectarlo aquí en enwiki. Si importamos que hemos no empeorar las cosas. Si alguien fuera a ese artículo, como podría hacer ahora, para configurar la descripción breve, en lugar de ver
"Delincuente condenado" - Importar - Importar y editar
que veríanBreve descripción: Penal condenado
. Por lo tanto, no tendría ningún efecto negativo en nuestro impulso actual incluir descripciones breves, y tendría el efecto beneficioso de evitar que futuros actos de vandalismo en Wikidata nos afecten. Además, se revisarían muchas de las ediciones del bot (nos gustaría que se espaciaran, no una avalancha de dos millones de ediciones en un mes) y eso tendría el beneficio adicional de limpiar algunas de las descripciones breves entrantes si están en hecho de vandalismo. No veo mucho negativo. ¿Qué me estoy perdiendo? Mike Christie ( charla - contribuciones - biblioteca ) 15:15, 28 de agosto de 2020 (UTC)- Tienes razón sobre la situación actual. Lo que falta es que WMF ha prometido dejar de mostrar descripciones de Wikidata, lo que eliminará muchas descripciones (buenas o malas) pero no las importadas por E1 o E2. Certes ( charla ) 15:45, 28 de agosto de 2020 (UTC)
- Tenía la impresión de que la promesa de dejar de mostrar las descripciones de Wikidata no se había implementado a pesar de que tenemos suficientes descripciones breves para cumplir con el requisito que establecieron, y no se les dio una fecha para hacer ese cambio. Estoy de acuerdo en que si creemos que sucederá pronto, eso marcará la diferencia, pero también creo que la funcionalidad es realmente útil en dispositivos móviles, y si la mayoría de las descripciones son correctas (y supongo que la gran mayoría lo es), entonces podríamos hacerlo. Bueno, importarlos y arreglarlos. Eso le ahorra mucho tiempo al editor al incluir descripciones breves, así que sospecho que sería un beneficio neto. ¿Tenemos evidencia de que la WMF realmente hará el cambio pronto? Si es así, cambiaría a un soporte débil para E1. Mike Christie ( charla - contribuciones - biblioteca ) 16:42, 28 de agosto de 2020 (UTC)
- Para mí, la WMF mantiene su promesa es una suposición necesaria, en el sentido de que si no lo hacen, entonces tengo la intención de dejar de editar y ya no me importará el resultado. Sin embargo, eso es un poco fuera de tema y puedo entender que otros editores tienen opiniones y objetivos diferentes. Certes ( charla ) 17:18, 28 de agosto de 2020 (UTC)
- Tenía la impresión de que la promesa de dejar de mostrar las descripciones de Wikidata no se había implementado a pesar de que tenemos suficientes descripciones breves para cumplir con el requisito que establecieron, y no se les dio una fecha para hacer ese cambio. Estoy de acuerdo en que si creemos que sucederá pronto, eso marcará la diferencia, pero también creo que la funcionalidad es realmente útil en dispositivos móviles, y si la mayoría de las descripciones son correctas (y supongo que la gran mayoría lo es), entonces podríamos hacerlo. Bueno, importarlos y arreglarlos. Eso le ahorra mucho tiempo al editor al incluir descripciones breves, así que sospecho que sería un beneficio neto. ¿Tenemos evidencia de que la WMF realmente hará el cambio pronto? Si es así, cambiaría a un soporte débil para E1. Mike Christie ( charla - contribuciones - biblioteca ) 16:42, 28 de agosto de 2020 (UTC)
- Tienes razón sobre la situación actual. Lo que falta es que WMF ha prometido dejar de mostrar descripciones de Wikidata, lo que eliminará muchas descripciones (buenas o malas) pero no las importadas por E1 o E2. Certes ( charla ) 15:45, 28 de agosto de 2020 (UTC)
- Bueno, dime si me equivoco, pero cualquier cosa que consideremos vandalismo ya está apareciendo, ¿verdad? Por ejemplo, si un BLP tiene una breve descripción de "criminal convicto" en Wikidata, lo estamos viendo en la búsqueda móvil ahora, pero no podemos detectarlo aquí en enwiki. Si importamos que hemos no empeorar las cosas. Si alguien fuera a ese artículo, como podría hacer ahora, para configurar la descripción breve, en lugar de ver
- Mike Christie, usted hace un punto válido de que una vez que las descripciones de Wikidata se copian en WP, cualquier vandalismo en Wikidata se vuelve irrelevante y podemos mejorarlas aquí, pero hasta que eso esté hecho, son nuestra responsabilidad para BLP, etc. ¿Quién sería responsable? ¿El propietario del bot? ¿La persona que autoriza la ejecución del bot? Además, ¿alguien sabe cuántas de las SD sobresalientes todavía tienen una versión de Wikidata disponible para copiar? Supongo que sería del orden de un millón, pero podría perder mucho. · · · Peter Southwood (charla) : 14:26, 28 de agosto de 2020 (UTC)
- Admite E2 , pero solo admite E1 después de que se ignoren las descripciones de Wikidata. No quiero ver más ediciones redundantes en mi lista de seguimiento hasta que sea realmente necesario. Nemo 11:06, 21 de agosto de 2020 (UTC)
- D1 y D2 obviamente no nos corresponde a nosotros decidir. E2 frustraría el propósito de las descripciones breves locales. No estoy seguro acerca de E1: suena como una buena idea, y ciertamente agradezco la perspectiva de que mi lista de seguimiento nunca más se vea abarrotada por editores humanos que importan descripciones de wikidata. Por otro lado, parece que las descripciones importadas a veces (¿a menudo?) Necesitan ser cambiadas, y no se cambiarán a menos que un humano las importe o los observadores las noten (un bot elimina la primera y reduce la probabilidad para el segundo). - Uanfala (charla) 18:03, 21 de agosto de 2020 (UTC)
- Me opongo firmemente a E2 porque el contenido de en.Wikipedia debe ser controlado por en.Wikipedia, no anulado por un proyecto diferente con diferentes estándares de calidad y diferentes compunciones sobre la creación de texto de bot masivo de baja calidad. Oponerse a D1 y D2 porque no deberíamos tomar decisiones aquí sobre lo que se almacena en Wikidata. Oponerse a E1 sobre el principio general de que el contenido de Wikidata es lo suficientemente dudoso como para que cada instancia de copia de texto de Wikidata a en.Wikipedia requiera que un humano le preste atención y verifique su validez, no solo una copia masiva por parte de bots. - David Eppstein ( charla ) 07:08, 22 de agosto de 2020 (UTC)
- Oponerse a E1 y E2 , sin comentarios sobre D1 y D2, que son asuntos que debe decidir la comunidad de Wikidata. Teniendo en cuenta que una descripción en Wikidata es una "frase descriptiva para un elemento, propiedad o consulta", mientras que una descripción en Wikipedia es una "explicación concisa del alcance de la página [artículo u otro espacio principal]"; Estos no son la misma cosa. También señalando que Wikidata es un wiki y, por lo tanto, es inherentemente poco confiable; no deberíamos importar nada de Wikidata. - Malcolmxl5 ( charla ) 15:11, 25 de agosto de 2020 (UTC)
- Oponerse a E1, oponerse enérgicamente a E2 No a E2 según muchos de los anteriores. En cuanto a E1, la calidad de las descripciones breves de Wikidata me parece demasiado errática para la importación al por mayor. Algunas son demasiado largas, otras son tan triviales que no tienen sentido y otras son simplemente incorrectas. No me opondría a una herramienta que permitiría revisar juntas una categoría de SDs, con casillas de verificación, permitiendo que todas las SD de Wikidata marcadas se importen a la vez. Eso aceleraría las cosas sin omitir la revisión del editor humano de este contenido altamente visible. Ya tenemos un script de usuario que permite listar las SD de página en una categoría. Consulte #Script para mostrar descripciones breves en las listas de categorías , a continuación. Podría usarse como base para un script de revisión .-- agr ( charla ) 23:42, 31 de agosto de 2020 (UTC)
- Fuerte oposición a E1 y E2 : No sé cuánta gente ha estado investigando y editando las descripciones breves y todo eso, pero puedo confirmar que ArnoldReinhold tiene razón: dicho con amabilidad, las descripciones breves de Wikidate son simplemente "demasiado erráticas". Los llamaría malos, francamente, e inadecuados para importarlos a nuestra Wikipedia. - Javert2113 ( Siarad. | ¤ ) 16:59, 1 de septiembre de 2020 (UTC)
Posibles alternativas
No veo que las propuestas anteriores obtengan aceptación, pero parte del problema que se pretende resolver es real. Necesitamos muchas más descripciones breves, y cuanto antes, mejor. No tienen que ser perfectos, solo lo suficientemente buenos, ya que pueden mejorarse en cualquier momento. Los incluyo para estimular el pensamiento y el debate, incluidas mejores propuestas. · · · Peter Southwood (charla) : 08:18, 8 de agosto de 2020 (UTC)
- Un sistema semiautomático que pasa por una categoría y proporciona sugerencias, una de las cuales se puede seleccionar y, si es necesario, editar antes de guardar. Una de las sugerencias sería la descripción de Wikidata, porque está ahí, y con bastante frecuencia se puede usar tal como está, y con bastante frecuencia se puede editar en algo mejor. El script para otras opciones podría diseñarse en torno a la categoría. No sé si esto sería más o menos trabajo que simplemente usar el dispositivo y un cerebro moderadamente informado.
- Los bots relativamente pequeños se ejecutan por categoría seguidos de controles manuales de calidad.
- Ejecuciones semiautomáticas, donde el bot se abre y muestra la SD propuesta, y el usuario debe aceptarla según corresponda para guardar.
- Ejecute un bot importante en toda la enciclopedia agregando una categoría de mantenimiento Categoría: artículos sin una breve descripción cuando sea relevante, para realizar un seguimiento de lo que queda por hacer.
- Solicite a NPP que considere agregar SD siempre que pueda: incluso podría hacer que una SD razonable sea una condición para aprobar la revisión, pero no voy a intentar impulsar más trabajo en NPP si no lo quieren.
- Active el gadget de forma predeterminada para los usuarios que hayan iniciado sesión. Sería necesario un RfC ya que, de lo contrario, es probable que se produzca un fuerte retroceso.
- Si Wikidata desea sincronizar sus descripciones para que coincidan con las utilizadas en Wikipedias, pueden actualizar Wikidata por cualquier medio que elijan que no cambie las descripciones breves de Wikipedia mediante un proceso automatizado.
Peter Southwood (charla) : 08:18, 8 de agosto de 2020 (UTC)
- Pregunta : No tengo nada en contra de las descripciones breves, pero ¿POR QUÉ hay prisa por agregarlas? No entiendo la idea de que más temprano es mejor que tarde. Creo que sería mejor un enfoque lento y deliberado ... ilumíname. Blueboar ( charla ) 18:21, 8 de agosto de 2020 (UTC)
- @ Blueboar : Porque la WMF nos ha dado un objetivo de dos millones , más allá del cual nos permitirán mucho más control. Consulte también WT: SHORTDESC y sus archivos. - Red rose64 🌹 ( charla ) 20:04, 8 de agosto de 2020 (UTC)
- Todavía estoy confundido ... ¿por qué WMF tiene tanta prisa? Blueboar ( charla ) 20:30, 8 de agosto de 2020 (UTC)
- @ Blueboar : Porque las cosas se romperán después de que WMF desactive el uso de las descripciones de Wikidata, lo cual apesta. Gracias. Mike Peel ( charla ) 20:19, 8 de agosto de 2020 (UTC)
- ¿Qué se romperá? Blueboar ( charla ) 20:30, 8 de agosto de 2020 (UTC)
- Actualmente, la "descripción breve" se utiliza en ciertos escenarios relacionados con la búsqueda móvil y el uso de la aplicación Wikipedia; si no hay una descripción breve, se usa en su lugar la descripción de Wikidata. La funcionalidad es extremadamente útil para navegar por el contenido de Wikipedia en dispositivos pequeños que representan aproximadamente la mitad de la base de lectores.
La comunidad de enwiki solicitó deshacerse del uso de descripciones de Wikidata una vez que se hayan creado ~ 2 millones de descripciones locales, que es el caso mientras tanto. Sin embargo, actualmente hay 2,4 millones de artículos que tienen una descripción de Wikidata, pero no una descripción corta de la Wikipedia en inglés local. Cuando se abandona el uso de las descripciones de Wikidata, una fracción realmente grande del contenido de enwiki se vuelve sustancialmente menos accesible para millones de lectores. - MisterSynergy ( charla ) 20:41, 8 de agosto de 2020 (UTC)- Ah ... entonces nada realmente se ROMPERÁ. La gente aún podrá leer y editar WP. Simplemente no será tan compatible con dispositivos móviles como podría ser. Gracias. Entiendo. Blueboar ( charla ) 20:59, 8 de agosto de 2020 (UTC)
- Es posible que WMF ya haya desactivado las descripciones de Wikidata. No he visto ningún anuncio, pero ya no veo descripciones breves sobre, por ejemplo, Abdomen , ni en la vista móvil ni con el dispositivo. Algunos pero no todos los demás editores siguen viendo la descripción, por lo que quizás solo se hayan actualizado algunos servidores. El cambio no parece haber roto nada más que eliminar algunas descripciones. Certes ( charla ) 20:51, 8 de agosto de 2020 (UTC)
- Actualmente, la "descripción breve" se utiliza en ciertos escenarios relacionados con la búsqueda móvil y el uso de la aplicación Wikipedia; si no hay una descripción breve, se usa en su lugar la descripción de Wikidata. La funcionalidad es extremadamente útil para navegar por el contenido de Wikipedia en dispositivos pequeños que representan aproximadamente la mitad de la base de lectores.
- ¿Qué se romperá? Blueboar ( charla ) 20:30, 8 de agosto de 2020 (UTC)
- @ Blueboar : Porque la WMF nos ha dado un objetivo de dos millones , más allá del cual nos permitirán mucho más control. Consulte también WT: SHORTDESC y sus archivos. - Red rose64 🌹 ( charla ) 20:04, 8 de agosto de 2020 (UTC)
- Muchas de estas parecen buenas ideas. ¿Pero # 6? Definitivamente no, ya que no todos los usuarios registrados son editores. Recuerde el WP: READER . {{u | Sdkb }} charla 20:24, 8 de agosto de 2020 (UTC)
- ¿Por qué la gente inicia sesión solo para leer? ¿Con qué frecuencia ocurre esto?
- ¿De qué manera activar el gadget de forma predeterminada sería un inconveniente para cualquiera que no tenga la intención de editar? · · · Peter Southwood (charla) : 11:05, 9 de agosto de 2020 (UTC)
- El inicio de sesión le permite establecer algunas preferencias que un lector podría querer establecer.
- Las descripciones breves no deben ser vistas por lectores de escritorio en una página. Mostrarlos a través del gadget cambiaría significativamente su propósito y abarrotaría la parte superior de cada página. Además, el dispositivo no los formatea lo suficientemente bien para un uso tan generalizado (no está claro qué son exactamente para los que no lo saben, y la sangría es un poco extraña; eso está bien para los editores, pero no lo sería para los lectores). {{u | Sdkb }} charla 20:12, 9 de agosto de 2020 (UTC)
- De hecho, las descripciones breves no estaban destinadas originalmente a ser vistas por lectores de escritorio. Es más discutible si poder verlos es una ventaja o una desventaja para los lectores de escritorio. La pantalla se puede cambiar a algo más estéticamente agradable, si alguien puede averiguar qué podría ser, o se puede dejar como opción, para evitar posibles inconvenientes a los lectores cuyas opiniones no se han probado actualmente, y tomar mucho más tiempo para terminar el trabajo porque la mayoría de los editores no saben que deberían existir. · · · Peter Southwood (charla) : 18:48, 13 de agosto de 2020 (UTC)
- La pregunta de cuántos lectores de escritorio que no editan realmente inician sesión permanece. ¿Es significativo? Es conocido ¿Se puede medir? · · · Peter Southwood (charla) : 18:52, 13 de agosto de 2020 (UTC)
Script para mostrar descripciones breves en listados de categorías
Me gustaría llamar la atención sobre un script de usuario creado recientemente que podría ser útil en esta discusión: Wikipedia_talk: WikiProject_Short_descriptions # Script_to_show_shortdescs_of_all_pages_in_a_category . Solicité este script y SD0001 tuvo la amabilidad de escribirlo. Además de ayudar a editar descripciones breves, creo que puede ser útil para tener una idea general de la calidad de las SD locales y de Wikidata. Sugeriría probarlo en algunas categorías con las que está familiarizado .-- agr ( charla ) 23:26, 31 de agosto de 2020 (UTC)
Eliminar el espacio de nombres Draft de $ wgNamespacesWithSubpages
En el espacio de nombres principal, no hay subpáginas, por lo que / es solo un carácter en el nombre de un artículo como cualquier otro. Por lo general, se supone que las páginas del espacio de nombres Borrador tienen el mismo nombre que tendrían en el espacio de nombres principal una vez aceptadas, por lo que tampoco tiene sentido tener subpáginas allí. Por ejemplo, Draft: Andreas Hedlund (arreglista / orquestador) no debe considerarse una subpágina de Draft: Andreas Hedlund (arreglista , y Draft: 9/11 Review Commission no debe considerarse una subpágina de Draft: 9. Y para mi conocimiento, no hay subpáginas legítimas e intencionales en uso en el espacio de nombres Draft. Como tal, propongo que eliminemos el espacio de nombres Draft de $ wgNamespacesWithSubpages . Jackmcbarn ( charla ) 04:12, 10 de agosto de 2020 (UTC)
- Páginas actuales bajo consideración: cantera: consulta / 47324 . Hay muchos intencionales allí, así que supongo que esto se reduce a lo que consideras "legítimo". - Críptico 05:19, 10 de agosto de 2020 (UTC)
- Casi todos parecen estar (1) usando barras inclinadas de una manera que no está destinada a ser subpáginas, (2) sobras de alguien que mueve "Usuario: Foo / Bar" a "Borrador: Foo / Bar" en lugar de directamente a "Borrador: Barra", o (3) un resultado de personas que utilizan el espacio de nombres Borrador para otras cosas que no sean redactar artículos. ¿Consideraría usted legítimo a alguno de ellos, o cree que hay algún otro grupo del que estoy subestimando el número? Jackmcbarn ( charla ) 23:25, 10 de agosto de 2020 (UTC)
- Creo que si estuviera editando muchos borradores de artículos a la vez, podría querer nombrarlos Draft: RexxS / Foo , Draft: RexxS / Bar , etc. para mantenerlos juntos, pero eso probablemente funcionaría de manera casi idéntica si las subpáginas fueran no permitido. Por supuesto, podría simplemente usar mi propio espacio de usuario para la redacción si realmente quisiera subpáginas, por lo que no veo ningún problema al eliminar el espacio de nombres en borrador de $ wgNamespacesWithSubpages. ¿Podemos estar seguros de lo que sucederá con el conjunto actual de páginas de borrador que contienen el /personaje cuando se cambie la configuración? - RexxS ( conversación ) 17:41, 11 de agosto de 2020 (UTC)
- @ RexxS : No sucederá nada en absoluto con los borradores que actualmente tienen una barra en su título. Seguirán estando accesibles con sus nombres actuales. Además, los usuarios aún podrán hacer borradores con esos títulos. Lo único que haría este cambio es cambiar la salida de {{BASEPAGENAME}} y {{SUBPAGENAME}} , deshacerse de los enlaces automáticos de ruta de navegación a las páginas principales, etc. Jackmcbarn ( charla ) 20:53, 11 de agosto de 2020 (UTC )
- @ Jackmcbarn : sí, me di cuenta de los que mencionaste, es solo el "etc." que me preocupaba - RexxS ( conversación ) 21:01, 11 de agosto de 2020 (UTC)
- @ RexxS : Habiendo revisado la documentación de MediaWiki, solo veo otros dos efectos: cualquier vínculo relativo se romperá, por lo que "[[/ bar]]" en "Draft: Foo" ahora se vincularía a "/ bar" en lugar de "Draft: Foo / bar ", y los borradores en movimiento ya no mostrarían una opción para mover sus subpáginas. Dado que se supone que los borradores eventualmente se convertirán en artículos, y ese tipo de enlaces no serían válidos en el espacio principal, no considero que sea una gran pérdida, y tampoco creo que movamos borradores con sus subpáginas muy a menudo (si siempre). Jackmcbarn ( charla ) 21:19, 11 de agosto de 2020 (UTC)
- ¿Se podría utilizar el espacio Draft: para un movimiento por turnos de una página con subpáginas, por ejemplo, una plantilla completa con / doc, / sandbox y / testcases, o un portal? Certes ( charla ) 21:28, 11 de agosto de 2020 (UTC)
- @ Certes : podría usar fácilmente su propio espacio de usuario para las páginas temporales. - RexxS ( conversación ) 21:36, 11 de agosto de 2020 (UTC)
- @ Certes y RexxS : WP: ROUNDROBIN actualmente recomienda usar una subpágina de Draft: Move para ese propósito, un comportamiento que se refleja en el popular script de usuario de intercambio de páginas . No estoy seguro de si esa funcionalidad requiere acceso a la opción "mover subpáginas" del lado de MediaWiki (que sería lo único realmente afectado por este cambio, hasta donde yo sé), pero ciertamente vale la pena señalar que este cambio puede interrumpir el flujo actualmente aceptado para movimientos por turnos. Nathan2055 talk - contribuciones 01:54, 23 de agosto de 2020 (UTC)
- @ Nathan2055 : Sería una tontería permitir que la ruta sugerida actualmente para realizar movimientos de página por turnos se convierta en un obstáculo para implementar una propuesta útil. Es trivial actualizar los consejos cuando cambian las circunstancias. Sin embargo, para los movimientos de una sola página, el consejo actual funcionaría de manera idéntica si se usara el espacio de borrador o el espacio de usuario como ubicación temporal. Un administrador que esté contemplando mover una página junto con todas sus subpáginas necesitaría comprender las limitaciones del espacio de nombres que estaban usando para las páginas temporales. Quizás podríamos acordar usar User: Example / Move como la raíz para tales movimientos. - RexxS ( charla ) 17:30, 23 de agosto de 2020 (UTC)
- @ Certes y RexxS : WP: ROUNDROBIN actualmente recomienda usar una subpágina de Draft: Move para ese propósito, un comportamiento que se refleja en el popular script de usuario de intercambio de páginas . No estoy seguro de si esa funcionalidad requiere acceso a la opción "mover subpáginas" del lado de MediaWiki (que sería lo único realmente afectado por este cambio, hasta donde yo sé), pero ciertamente vale la pena señalar que este cambio puede interrumpir el flujo actualmente aceptado para movimientos por turnos. Nathan2055 talk - contribuciones 01:54, 23 de agosto de 2020 (UTC)
- @ Certes : podría usar fácilmente su propio espacio de usuario para las páginas temporales. - RexxS ( conversación ) 21:36, 11 de agosto de 2020 (UTC)
- ¿Se podría utilizar el espacio Draft: para un movimiento por turnos de una página con subpáginas, por ejemplo, una plantilla completa con / doc, / sandbox y / testcases, o un portal? Certes ( charla ) 21:28, 11 de agosto de 2020 (UTC)
- @ RexxS : Habiendo revisado la documentación de MediaWiki, solo veo otros dos efectos: cualquier vínculo relativo se romperá, por lo que "[[/ bar]]" en "Draft: Foo" ahora se vincularía a "/ bar" en lugar de "Draft: Foo / bar ", y los borradores en movimiento ya no mostrarían una opción para mover sus subpáginas. Dado que se supone que los borradores eventualmente se convertirán en artículos, y ese tipo de enlaces no serían válidos en el espacio principal, no considero que sea una gran pérdida, y tampoco creo que movamos borradores con sus subpáginas muy a menudo (si siempre). Jackmcbarn ( charla ) 21:19, 11 de agosto de 2020 (UTC)
- @ Jackmcbarn : sí, me di cuenta de los que mencionaste, es solo el "etc." que me preocupaba - RexxS ( conversación ) 21:01, 11 de agosto de 2020 (UTC)
- @ RexxS : No sucederá nada en absoluto con los borradores que actualmente tienen una barra en su título. Seguirán estando accesibles con sus nombres actuales. Además, los usuarios aún podrán hacer borradores con esos títulos. Lo único que haría este cambio es cambiar la salida de {{BASEPAGENAME}} y {{SUBPAGENAME}} , deshacerse de los enlaces automáticos de ruta de navegación a las páginas principales, etc. Jackmcbarn ( charla ) 20:53, 11 de agosto de 2020 (UTC )
- Creo que si estuviera editando muchos borradores de artículos a la vez, podría querer nombrarlos Draft: RexxS / Foo , Draft: RexxS / Bar , etc. para mantenerlos juntos, pero eso probablemente funcionaría de manera casi idéntica si las subpáginas fueran no permitido. Por supuesto, podría simplemente usar mi propio espacio de usuario para la redacción si realmente quisiera subpáginas, por lo que no veo ningún problema al eliminar el espacio de nombres en borrador de $ wgNamespacesWithSubpages. ¿Podemos estar seguros de lo que sucederá con el conjunto actual de páginas de borrador que contienen el /personaje cuando se cambie la configuración? - RexxS ( conversación ) 17:41, 11 de agosto de 2020 (UTC)
- Casi todos parecen estar (1) usando barras inclinadas de una manera que no está destinada a ser subpáginas, (2) sobras de alguien que mueve "Usuario: Foo / Bar" a "Borrador: Foo / Bar" en lugar de directamente a "Borrador: Barra", o (3) un resultado de personas que utilizan el espacio de nombres Borrador para otras cosas que no sean redactar artículos. ¿Consideraría usted legítimo a alguno de ellos, o cree que hay algún otro grupo del que estoy subestimando el número? Jackmcbarn ( charla ) 23:25, 10 de agosto de 2020 (UTC)
- Soporte Los usuarios que quieran organizar sus borradores usando subpáginas pueden usar su espacio de usuario; los usuarios que quieran realizar movimientos de página por turnos con subpáginas pueden utilizar el espacio de usuario o el espacio del proyecto; los casos de uso restantes no serían válidos en el espacio principal, por lo que no veo una pérdida. DYK tiene muchos problemas con las barras diagonales porque su espacio de nombres tiene subpáginas cuando main no las tiene, por lo que esto probablemente facilitaría la vida de algunos desarrolladores en el futuro. - Wug · a · po · des 20:47, 20 de agosto de 2020 (UTC)
- Soporte : tiene mucho sentido para mí. Evitará que las cosas se rompan al trabajar en borradores en espacios de corrientes de aire. A a s i m 02:12, 26 de agosto de 2020 (UTC)
- Soporte Tiene sentido que los espacios utilizados para propósitos similares funcionen de la misma manera. · · · Peter Southwood (charla) : —Se agregó un comentario sin fecha anterior a las 08:09, 28 de agosto de 2020 (UTC)
Migrar datos de colores universitarios a Wikidata
Hay una discusión en curso sobre la migración de algunos datos de color de equipos deportivos de un módulo de Lua local a Wikidata: Charla del módulo: Color de la universidad # Propuesta: Migrar a Wikidata . - Iago Qnsi ( charla ) 07:35, 11 de agosto de 2020 (UTC)
- Otro caso más de "Oye, podríamos usar Wikidata para hacer lo que ya hacemos". No, gracias. Blueboar ( charla ) 21:50, 11 de agosto de 2020 (UTC)
- Oponerse solo serviría para facilitar el vandalismo sutil. Sin beneficio. DES (charla) DESiegel Contribs 02:14, 13 de agosto de 2020 (UTC)
- @ DESiegel : Como mencioné en la página de discusión del módulo, hay muchas formas de monitorear los datos y combatir el vandalismo. A continuación, se muestra una consulta que muestra los cambios más recientes en las propiedades de color de los equipos deportivos universitarios. Un bot podría configurarse fácilmente para actualizar una página aquí en Wikipedia con los resultados de la consulta y mostrar esos colores visualmente para que los colores incorrectos puedan detectarse fácilmente. Si el vandalismo se volvió desenfrenado, Wikidata tiene las mismas herramientas de protección que tenemos en Wikipedia, e iirc, la política allí dice que los elementos altamente visibles son elegibles para protección indefinida si es necesario.
- En cuanto a la parte "sin beneficio", es cierto que tiene un beneficio limitado para Wikipedia en inglés. Pero tiene un gran potencial para beneficiar a otras Wikipedias y al resto de la comunidad Wikimedia. Tener una base de datos de los colores de los equipos deportivos universitarios, disponible de forma gratuita, actualizada periódicamente y respaldada por referencias, es de gran valor para el público en general; Puedo prever que estos se utilizarán para visualizaciones de datos geniales. - Iago Qnsi ( charla ) 00:09, 14 de agosto de 2020 (UTC)
- Si aquellos que ejecutan Wikidata quieren importar estos datos, pueden hacerlo y otros proyectos son libres de usarlos. En este punto, no confío en el abastecimiento y la validación realizados en Wikidata, y me opongo firmemente a que cualquier información en cualquier artículo de en.Wikipedia se importe automáticamente desde Wikidata. Sin excepciones. Hace algunos años opiné en un RFC que no deberíamos hacer ningún uso de Wikidata en los artículos, y hoy mantengo esa opinión. Me opongo a todas y cada una de las ampliaciones del uso de Wikidata aquí. DES (charla) DESiegel Contribs 00:15, 14 de agosto de 2020 (UTC)
- Soporte Los beneficios son muchos y creo que IagoQnsi podría tener más que decir. Centralizar los datos para que sean accesibles a los más de 300 wikis simplemente tiene sentido. Solo necesita cambiar los datos en un solo lugar en lugar de 300. Controle el vandalismo en un solo lugar. Corrija los errores en un solo lugar. etc .. Existen herramientas y métodos para el monitoreo del vandalismo, que serían parte del trato para la aceptación de un método robusto. Como señaló IagoQnsi, hay aplicaciones futuras que no están disponibles actualmente y que podrían construirse con una base de datos de color central, no solo con equipos deportivos universitarios. - Green C 02:54, 13 de agosto de 2020 (UTC)
- Módulo de soporte : College color / data es un truco horrible para almacenar datos, nunca debería haber sido creado y es una pesadilla de usabilidad para cualquiera que quiera cambiar algo en él. Wikidata puede manejar esto de una manera más fácil de usar y entre wiki, con mejores herramientas de monitoreo a través de violaciones de restricciones y consultas de datos. Gracias. Mike Peel ( charla ) 19:45, 13 de agosto de 2020 (UTC)
- Pregunta: ¿Cómo se almacenarían en Wikidata las 794 plantillas de citas del Módulo: Color / datos universitarios ? - RexxS ( conversación ) 23:11, 13 de agosto de 2020 (UTC)
- @ RexxS : Wikidata admite adjuntar referencias a declaraciones; ver wikidata: Ayuda: Fuentes . Ejecuté un script contra todas las plantillas de referencia para obtener la lista completa de parámetros que usan, que son los siguientes: fecha de acceso, fecha de archivo, url de archivo, fecha, idioma, página, editor, título, url, url- estado, sitio web, trabajo, año. Todos ellos tienen propiedades correspondientes en Wikidata, por lo que se pueden importar con bastante facilidad. Las propiedades 'editor', 'sitio web' y 'trabajo' deberán asignarse a elementos de Wikidata (porque las propiedades de Wikidata correspondientes toman un elemento en lugar de una cadena). Sin embargo, acabo de comprobarlo, y hay menos de 100 usos de todas esas propiedades combinadas, por lo que serán fáciles de reconciliar con OpenRefine . - Iago Qnsi ( charla ) 23:45, 13 de agosto de 2020 (UTC)
- @ IagoQnsi : Por favor, eche un vistazo a MOS: INDENTMIX . Acabas de hacer un lío con este hilo para cualquiera que use un lector de pantalla. (respuesta: ¡arreglado! - Iago Qnsi ( charla ) 01:35, 14 de agosto de 2020 (UTC)) No del todo. - RexxS ( conversación ) 01:50, 14 de agosto de 2020 (UTC)
- Sí, estoy seguro de que la mayoría de los parámetros se pueden almacenar en Wikidata, incluso si tiene que crear cientos de nuevas entradas de Wikidata para adaptarse a la falta de coincidencia de tipos de datos (y más cada vez que se agregan nuevas citas). ¿Cómo piensa almacenar el tipo de plantilla de cita utilizada, de modo que la cita se pueda reconstruir con precisión? Dado ese tipo de problemas, debes preguntarte si Wikidata es realmente el mejor lugar para almacenar este tipo de datos. - RexxS ( charla ) 00:51, 14 de agosto de 2020 (UTC)
- @ RexxS : No espero tener que crear muchos elementos nuevos, si es que hay alguno. Como dije, esas 794 citas combinadas tienen <100 usos de parámetros que deben asignarse a elementos de Wikidata. Y la mayoría / todos esos usos no requerirán elementos nuevos: la mayoría de las referencias fueron publicadas por una universidad y ya tenemos elementos WD para cada universidad.
- En cuanto al tipo de plantilla utilizada, todas estas citas usan {{ cite web }} o {{ cite manual }}. La distinción parece un poco arbitraria (es decir, muchos de los 'cite web' parecen que deberían considerarse manuales), pero podría almacenar el tipo de referencia (P3865) = guía del usuario (Q1057179) para los 'cite manual' si me gustaría. Pero en última instancia, el objetivo aquí no es poder generar exactamente el mismo wikitexto subyacente, sino generar una cita con el mismo significado semántico. Realmente, el resultado es que las citas serán mucho más limpias: en Wikipedia, a menudo terminas con información distribuida de manera bastante aleatoria entre 'trabajo' y 'editor' y 'título', pero Wikidata te obliga a ser más consistente. - Iago Qnsi ( charla ) 01:35, 14 de agosto de 2020 (UTC)
- @ IagoQnsi : Creo que puede encontrar que los editores que usan colores universitarios probablemente estén bastante interesados en recrear el wikitexto subyacente exacto. ¿Ha considerado el flujo de trabajo para que un editor agregue una entrada al módulo Scribunto (no es simple, pero hay muchos ejemplos para copiar y la cita usa un formato con el que estarán familiarizados), con eso para agregar un color universitario a Wikidata, incluyendo todo el trabajo de deconstruir una cita en múltiples calificadores de referencia no obvios. Vale la pena pensarlo. - RexxS ( conversación ) 01:50, 14 de agosto de 2020 (UTC)
- @ RexxS : No es que no pudiéramos recrearlos exactamente como están escritos; es que tiene mucho más sentido limpiarlos para que se vean mejor de lo que están escritos actualmente. No hay razón para preservar perfectamente cosas desordenadas como
|title=Color {{!}} Brand and Messaging {{!}} University of Colorado at Boulder
. Por ejemplo, tome esta cita:{{cite web |url=https://brand.cornell.edu/design-center/colors/ |title=Colors |publisher=Cornell University Brand Center |accessdate=July 17, 2019}}
no vale la pena crear un elemento nuevo para el "Centro de marca de la Universidad de Cornell", así que cuando lo transfiera a Wikidata, probablemente lo transforme para que se vea así:
- @ RexxS : No es que no pudiéramos recrearlos exactamente como están escritos; es que tiene mucho más sentido limpiarlos para que se vean mejor de lo que están escritos actualmente. No hay razón para preservar perfectamente cosas desordenadas como
- @ IagoQnsi : Creo que puede encontrar que los editores que usan colores universitarios probablemente estén bastante interesados en recrear el wikitexto subyacente exacto. ¿Ha considerado el flujo de trabajo para que un editor agregue una entrada al módulo Scribunto (no es simple, pero hay muchos ejemplos para copiar y la cita usa un formato con el que estarán familiarizados), con eso para agregar un color universitario a Wikidata, incluyendo todo el trabajo de deconstruir una cita en múltiples calificadores de referencia no obvios. Vale la pena pensarlo. - RexxS ( conversación ) 01:50, 14 de agosto de 2020 (UTC)
- @ RexxS : Wikidata admite adjuntar referencias a declaraciones; ver wikidata: Ayuda: Fuentes . Ejecuté un script contra todas las plantillas de referencia para obtener la lista completa de parámetros que usan, que son los siguientes: fecha de acceso, fecha de archivo, url de archivo, fecha, idioma, página, editor, título, url, url- estado, sitio web, trabajo, año. Todos ellos tienen propiedades correspondientes en Wikidata, por lo que se pueden importar con bastante facilidad. Las propiedades 'editor', 'sitio web' y 'trabajo' deberán asignarse a elementos de Wikidata (porque las propiedades de Wikidata correspondientes toman un elemento en lugar de una cadena). Sin embargo, acabo de comprobarlo, y hay menos de 100 usos de todas esas propiedades combinadas, por lo que serán fáciles de reconciliar con OpenRefine . - Iago Qnsi ( charla ) 23:45, 13 de agosto de 2020 (UTC)
- Pregunta: ¿Cómo se almacenarían en Wikidata las 794 plantillas de citas del Módulo: Color / datos universitarios ? - RexxS ( conversación ) 23:11, 13 de agosto de 2020 (UTC)
Propiedad |
| ||||||||||||||||||||||||||||||||||
+ agregar valor |
- Esto no es exactamente lo mismo, pero es básicamente un cambio neutral, si no una mejora. Y si vuelvo a introducir esos datos en {{ citation }}, obtienes esta cita perfectamente cromulenta:
"Colors", Cornell University Brand Center , Cornell University , consultado el 17 de julio de 2019
(a modo de comparación, aquí está la cita original:"Colores" . Centro de Marca de la Universidad de Cornell . Consultado el 17 de julio de 2019 .
). - Iago Qnsi ( charla ) 02:29, 14 de agosto de 2020 (UTC)- @ IagoQnsi : Intente observar MOS: INDENTMIX . No es muy amable con los lectores de pantalla estropear la sangría como lo hace usted. Si lee WP: CITEVAR , creo que encontrará que los cambios que ha realizado están lejos de ser neutrales. Aparte de la obvia reasignación de título y editor, ha cambiado el estilo de la cita de {{ cite web }} a {{ citation }}, lo que nunca debería suceder. También establece la fecha de acceso en formato mdy. ¿Cómo recuperaste esa información de tu registro de Wikidata? Este es el tipo de problemas con los que he estado lidiando durante los últimos siete años con Module: WikidataIB y me fascinaría ver cómo crees que los has resuelto. - RexxS ( charla ) 03:51, 14 de agosto de 2020 (UTC)
- Esto no es exactamente lo mismo, pero es básicamente un cambio neutral, si no una mejora. Y si vuelvo a introducir esos datos en {{ citation }}, obtienes esta cita perfectamente cromulenta:
- outdented - GhostInTheMachine me habla 10:16, 29 de agosto de 2020 (UTC)
- @ RexxS : Entiendo la necesidad de no cambiar las citas que ya están perfectamente bien, pero ese no es el caso aquí. Si examina las citas de este módulo, hay poca coherencia entre ellas. Se alternan entre comillas y cursiva; algunos están en mayúsculas al azar; el nombre del editor a veces se encuentra en el campo del título, a veces en el campo del trabajo / sitio web y, a veces, está completamente ausente. En general, todos estos se ven como los autores que pegaron en su URL, hicieron clic en "autocompletar" en la herramienta de citas que eligieron y terminaron el día. Estaría más que feliz de preservar cualquier estilo de cita existente, pero simplemente no hay uno aquí.
- Separar el contenido del estilo es realmente el propósito de Wikidata. Puede mostrar información de Wikidata con cualquier estilo de cita, cualquier formato de fecha, incluso el idioma que desee. Si desea mostrar una de estas citas en un artículo que usa {{ citation }}, puede hacerlo; si desea utilizar {{ cite web }} o cualquier otra cosa, también puede hacerlo. El objetivo de migrar a Wikidata no es forzar ningún estilo de presentación en particular; es simplemente separar los datos de la presentación. - Iago Qnsi ( charla ) 06:18, 14 de agosto de 2020 (UTC)
- @ IagoQnsi : Me temo que está equivocado acerca de las citas almacenadas en el Módulo: Color / datos de la universidad . Aparte de una fecha de acceso en formato ISO, son notablemente consistentes. No hay un solo ejemplo de cursiva codificada en las citas. Su queja sobre "citas y cursiva" es una consecuencia de MOS: ITAL :
"Utilice cursiva para los títulos de las obras (como libros, películas, series de televisión, exposiciones con nombre, juegos de computadora, álbumes de música y pinturas). Los títulos de artículos, capítulos, canciones, episodios, trabajos de investigación y otras obras breves en su lugar toman comillas dobles.
Las plantillas de citas son lo suficientemente inteligentes como para usar el formato apropiado para que coincida con nuestro Manual de estilo. El estilo de cita utilizado es WP: CS1 y se encontrará con grandes problemas si cree que puede cambiar a otro estilo a voluntad. Tendrá que preservar el estilo de las citas que se utiliza, independientemente de cómo se almacenen, por lo que será necesario resolver ese problema antes de que Wikidata se convierta en un mecanismo de almacenamiento viable para las citas. Separar el contenido de la presentación es un artefacto de Wikidata, no su propósito (que sería "almacenar datos"). Desafortunadamente, Wikidata está actualmente estructurado para adaptarse a la importación de datos sin formato, sin pensar en cómo exportarlos y reutilizarlos. Si se va a utilizar como back-end de base de datos para un artículo de Wikipedia, debe ser capaz de respetar las opciones de presentación que se utilizan actualmente en ese artículo. Las plantillas de citas pueden hacer mucho de ese trabajo por usted (incluso pueden detectar el formato de fecha en artículos que han establecido uno), pero decidir el estilo de cita que debe usarse en un artículo en particular es actualmente el obstáculo para los intentos. para almacenar citas en cualquier formato que no sea texto wiki. - RexxS ( charla ) 12:45, 14 de agosto de 2020 (UTC)- @ RexxS : Si el estilo de la cita se almacenara en Wikidata, causaría violaciones de WP: CITEVAR , no las evitaría. Así es como se desarrollaría: ClaimX en Wikidata se usa en dos artículos de Wikipedia: ArticleA (que usa {{ cite web }}) y ArticleB (que usa {{ citation }}). Ahora, suponga que Usuario: Ejemplo actualiza ClaimX para usar {{ cite web }}. En este caso hipotético, estamos almacenando información de estilo en Wikidata, lo que significa que ClaimX ahora aparecerá en ArticleB con {{ cite web }}. ¡Oh no, esto viola WP: CITEVAR !
- Por lo tanto, así es como lo hacemos: ClaimX en Wikidata tiene una cita sin un estilo definido. ArticleA y ArticleB tanto de importación ClaimX , pero cada uno de ellos la hacen en un estilo diferente. Usuario: Ejemplo hace una edición en ClaimX . Debido a que Wikidata no almacena información sobre el estilo de las citas, la cita seguirá apareciendo en {{ cite web }} en ArticleA y en {{ citation }} en ArticleB . Las citas siguen siendo constantes, se obedece WP: CITEVAR y todos están contentos. - Iago Qnsi ( charla ) 05:31 18 de agosto de 2020 (UTC)
- @ IagoQnsi : ¿Crees que
" ArticleA y ArticleB tanto de importación ClaimX , pero cada uno de ellos la hacen en un estilo diferente."
por lo que la cita tiene que ser hecha a mano para cada artículo, derrotando así el objeto del Módulo: Color de la universidad , que tiene como objetivo mostrar la información de forma automática. Solo mire el Módulo: College color / doc #Test table para ver un ejemplo obvio. La tabla se genera en una línea:,{{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD }}
pero su solución requeriría que se escribieran 1132 filas individualmente para que pueda proporcionar las referencias en el formato que desee. El objetivo de Module: College color es que almacena el estilo de cita de cada equipo junto con su combinación de colores. La ventaja de eso es que Abilene Christian Wildcats no tiene que tener el mismo estilo de referencia que los pingüinos estatales de Youngstown . La desventaja es que si se escribe otro artículo sobre Abilene Christian Wildcats, necesita el mismo estilo de cita que el artículo base, pero esa es la ruta que han tomado los escritores y mantenedores, y no veo que deba obligarlos a hacerlo. hacer mucho más trabajo en cada artículo solo para evitar almacenar el estilo de cita, que su solución no puede ofrecer. - RexxS ( charla ) 17:17, 18 de agosto de 2020 (UTC)- @ RexxS : Las citas no tendrían que presentarse individualmente; tendrías una plantilla / módulo que los renderiza todos, y simplemente le dices a esa plantilla cómo diseñarlos a todos. Algo como:
{{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD |citation-style=CS1 |date-format=mdy }}
- Iago Qnsi ( charla ) 20:11, 18 de agosto de 2020 (UTC)- @ IagoQnsi : ¿Entonces escribe otra plantilla / módulo con 1132 filas solo para mostrarlas todas? Ya tenemos un módulo que hace eso en una línea. De lo contrario, ¿cómo se
{{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD '''|citation-style=CS1''' |date-format=mdy }}
sabe cuál es el valor de|citation-style=
? Me ha dicho que no lo va a almacenar en Wikidata con el resto de los datos. - RexxS ( charla ) 02:24, 19 de agosto de 2020 (UTC)- @ RexxS : Mi comprensión de su argumento es básicamente que el estilo de cualquier cita dada nunca debería cambiar. Sin embargo, eso no es exactamente lo que dice WP: CITEVAR . Se lee
Los editores no deben intentar cambiar un artículo que está establecida estilo de citación
(énfasis añadido). El estilo de las citas se establece por artículo , no por cita . Con base en esa política, no hay razón para que una cita determinada deba tener un estilo determinado; en su lugar, debe ser renderizado en el estilo del artículo en el que aparece. Eso es lo que indicaría la política actual, y francamente, lo que tiene más sentido. - Déjame dar un ejemplo. Supongamos que yo (un editor humano) vi un hecho citación apoyado en ArticleA , y decidí que ese hecho (y su cita) también serían útiles para incluir en ArticleB . En el proceso de copiar esta información, seguramente editaría la cita para convertirla al estilo de cita del Artículo B , ¿no es así? Si la cita de ArticleA está en estilo {{ citation }}, pero ArticleB usa {{ cite web }}, entonces necesitaría convertir esa cita para usar {{ cite web }}, ¿verdad? Si es aceptable para mí cambiar el estilo de una cita al moverla a un nuevo artículo, ¿por qué no debería estar bien que Wikidata también lo haga? - Iago Qnsi ( charla ) 17:59, 26 de agosto de 2020 (UTC)
- @ IagoQnsi : Parece que no entiende cómo se usa este módulo. Cada una de las entradas de color se aplica efectivamente a un artículo, y el módulo de datos almacena no solo la información de color para el equipo de ese artículo, sino también el estilo de cita utilizado en ese artículo. Así es como funciona ahora. Desea cambiar la forma en que funciona para que se adapte a la capacidad de su esquema de almacenar información y desechar la información sobre el estilo de cita que se utilizará. Los editores que crearon y utilizan este módulo lo utilizan ahora de forma sencilla; y les pedirá que almacenen localmente una lista separada de artículos con sus estilos de citas, o que inserten el estilo de las citas manualmente en cada artículo, por ningún motivo que no sea que la solución propuesta no pueda funcionar de la forma en que lo hacen. trabajando ahora. Esa es la cola que mueve al perro.
- Veamos tu ejemplo. Supones que los colores para el equipo A, que se utiliza en ArticleA podrían ser útiles en alguna manera ArticleB . No veo evidencia de que ese sea el caso. En el sistema actual, que sigue siendo trivial de lograr cuando ArticleB tiene el mismo estilo de citación como ArticleA ; simplemente copie la plantilla relevante y generará la cita para usted. Requeriría la actualización manual de la cita si los estilos fueran diferentes. Sin embargo, en su esquema, la cita tendría que configurarse localmente en el caso de cada Artículo A para que coincida con su estilo existente (no ha dado ningún ejemplo de cómo podría lograrse), y luego configurarse de nuevo localmente si quería usarlo en el artículo B, ya sea que el estilo coincida o no. No veo eso como una ventaja. No hay ningún beneficio demostrado de desvincular el estilo de cita utilizado en el artículo de cada equipo de la información almacenada en el módulo. En la actualidad existe efectivamente una correspondencia uno a uno entre el artículo y la entrada en el módulo de datos, lo que permite un método de almacenamiento sencillo. Está defendiendo el uso de un sistema de almacenamiento más complejo (algo de información en Wikidata; algo de información localmente) para permitir la posibilidad de que en algún lugar los editores quieran una correspondencia de dos a uno (o más) entre la información del artículo y los colores, pero usted no lo ha hecho. No demostró ninguna necesidad o demanda para eso. - RexxS ( charla ) 19:06, 26 de agosto de 2020 (UTC)
- @ RexxS : este módulo no se utiliza en absoluto para un solo artículo. Los colores de cada escuela se utilizan probablemente en cientos de artículos cada uno, ya que tenemos muchos artículos que cubren deportes universitarios. Para dar un ejemplo, los colores de los Duke Blue Devils se transcluídas en la Universidad de Duke , Duke Blue Devils , el baloncesto de Duke Blue Devils hombres , equipo de baloncesto de los hombres 1990-1991 Duke Blue Devils , Atlantic Coast Conference , 2018-19 Atlantic Coast Conference temporada de baloncesto de los hombres , y todas las variaciones de esos artículos (es decir, otros años / temporadas, otros deportes). Si tuviéramos que transferir los datos a Wikidata, los colores también serían utilizados por muchas páginas en otras ediciones de Wikipedia, que presumiblemente tendrían sus propios estilos de citas.
- Establecer el estilo no sería difícil. Presumiblemente, usaríamos el estilo CS1 de forma predeterminada, que se usa en una abrumadora mayoría de artículos deportivos universitarios que he encontrado. Pero esto podría anularse fácilmente por uso (p. Ej., {{College color boxes | citation = cs2}}) o por artículo, usando algo como {{ Use CS2 }} (que podría funcionar en el de la misma forma que las plantillas como {{ Usar fechas mdy }} funcionan actualmente). Actualmente, las citas del módulo no se incluyen en los artículos, por lo que todo esto es hipotético por ahora. - Iago Qnsi ( charla ) 19:52, 26 de agosto de 2020 (UTC)
- @ IagoQnsi : En la actualidad, cualquier artículo que desee utilizar la cita almacenada en el módulo puede hacerlo de forma trivial. Las citas almacenadas en el módulo son una mezcla casi igual de {{ cite web }} y {{ cite manual }} con un par de {{ cite book }}.
- Tu aseguras
"Ajuste del estilo no sería difícil ... esto podría ser fácilmente anulado ... usando algo como {{ Uso CS2 }}"
He aquí una cita:{{cite manual |url=http://www.thepacwest.com/documents/2015/6/22//pacWest_colorways_spring2015.pdf |title=Pacific West Conference Visual Identity Standards |accessdate=March 23, 2017}}
. Me gustaría que me mostrara cómo no es difícil configurar CS2 para ello. Por favor, avíseme aproximadamente cuánto tiempo tendré que esperar para obtener su solución. - RexxS ( charla ) 21:30, 27 de agosto de 2020 (UTC)- @ RexxS : Si tiene esa cita almacenada en Wikidata, es muy fácil escupirla en cualquier estilo. Los parámetros son exactamente los mismos entre {{ cite manual }} y {{ citation }}; de hecho, ambos se basan en el mismo módulo subyacente. Nuestra plantilla pasaría todos los parámetros de referencia a Module: Citation / CS1 , luego establecería CitationClass en "citation" si la página usa CS2, o en uno de los valores de CS1 (por ejemplo, libro, web, noticias, etc.) si la página usa CS1. Tendría que haber un poco de lógica para decidir qué valor de CS1 usar; básicamente, si la referencia incluye un tipo de valor de referencia (P3865) , simplemente usaríamos el CitationClass que corresponde a ese tipo de medio; de lo contrario, haríamos una mejor estimación basada en las propiedades incluidas, muy similar a cómo lo hace {{ citation }}. - Iago Qnsi ( charla ) 22:45, 27 de agosto de 2020 (UTC)
- @ IagoQnsi : Está bien, enséñamelo . Estoy realmente interesado en ese "poco de lógica para decidir qué valor de CS1 usar". Luego le preguntaré cómo manejará los títulos de capítulos y artículos que se definen de manera diferente en CS1 y CS2. - RexxS ( conversación ) 23:20, 27 de agosto de 2020 (UTC)
- @ RexxS : Si se establece el tipo de referencia (P3865) , entonces podemos tener un mapeo de matriz 1 a 1 de elementos de tipo de referencia a valores de CitationClass (por ejemplo, libro de mapas (Q571) a CitationClass = 'libro', etc.). Si P3865 no está configurado, entonces miramos qué propiedades están configuradas. Una solución muy rudimentaria sería usar 'libro' si se configuran volumen / edición / página y, de lo contrario, usar 'web'. Esa no es una solución sólida, claro, pero ya es más que suficiente para manejar todas las referencias existentes en este módulo. No propongo que migremos todas las citas de Wikipedia a Wikidata; Solo estoy proponiendo que migremos los de este módulo. La implementación mejorará con el tiempo si se está utilizando y comienzan a surgir casos extremos. - Iago Qnsi ( charla ) 23:56, 27 de agosto de 2020 (UTC)
- @ IagoQnsi : No parece que me hayas mostrado nada. Y me temo que ese tipo de referencia (P3865) no significa lo que crees que hace . - RexxS ( charla ) 00:14, 28 de agosto de 2020 (UTC)
- @ RexxS : Si se establece el tipo de referencia (P3865) , entonces podemos tener un mapeo de matriz 1 a 1 de elementos de tipo de referencia a valores de CitationClass (por ejemplo, libro de mapas (Q571) a CitationClass = 'libro', etc.). Si P3865 no está configurado, entonces miramos qué propiedades están configuradas. Una solución muy rudimentaria sería usar 'libro' si se configuran volumen / edición / página y, de lo contrario, usar 'web'. Esa no es una solución sólida, claro, pero ya es más que suficiente para manejar todas las referencias existentes en este módulo. No propongo que migremos todas las citas de Wikipedia a Wikidata; Solo estoy proponiendo que migremos los de este módulo. La implementación mejorará con el tiempo si se está utilizando y comienzan a surgir casos extremos. - Iago Qnsi ( charla ) 23:56, 27 de agosto de 2020 (UTC)
- @ IagoQnsi : Está bien, enséñamelo . Estoy realmente interesado en ese "poco de lógica para decidir qué valor de CS1 usar". Luego le preguntaré cómo manejará los títulos de capítulos y artículos que se definen de manera diferente en CS1 y CS2. - RexxS ( conversación ) 23:20, 27 de agosto de 2020 (UTC)
- @ RexxS : Si tiene esa cita almacenada en Wikidata, es muy fácil escupirla en cualquier estilo. Los parámetros son exactamente los mismos entre {{ cite manual }} y {{ citation }}; de hecho, ambos se basan en el mismo módulo subyacente. Nuestra plantilla pasaría todos los parámetros de referencia a Module: Citation / CS1 , luego establecería CitationClass en "citation" si la página usa CS2, o en uno de los valores de CS1 (por ejemplo, libro, web, noticias, etc.) si la página usa CS1. Tendría que haber un poco de lógica para decidir qué valor de CS1 usar; básicamente, si la referencia incluye un tipo de valor de referencia (P3865) , simplemente usaríamos el CitationClass que corresponde a ese tipo de medio; de lo contrario, haríamos una mejor estimación basada en las propiedades incluidas, muy similar a cómo lo hace {{ citation }}. - Iago Qnsi ( charla ) 22:45, 27 de agosto de 2020 (UTC)
- @ RexxS : Mi comprensión de su argumento es básicamente que el estilo de cualquier cita dada nunca debería cambiar. Sin embargo, eso no es exactamente lo que dice WP: CITEVAR . Se lee
- @ IagoQnsi : ¿Entonces escribe otra plantilla / módulo con 1132 filas solo para mostrarlas todas? Ya tenemos un módulo que hace eso en una línea. De lo contrario, ¿cómo se
- @ RexxS : Las citas no tendrían que presentarse individualmente; tendrías una plantilla / módulo que los renderiza todos, y simplemente le dices a esa plantilla cómo diseñarlos a todos. Algo como:
- @ IagoQnsi : ¿Crees que
- @ IagoQnsi : Me temo que está equivocado acerca de las citas almacenadas en el Módulo: Color / datos de la universidad . Aparte de una fecha de acceso en formato ISO, son notablemente consistentes. No hay un solo ejemplo de cursiva codificada en las citas. Su queja sobre "citas y cursiva" es una consecuencia de MOS: ITAL :
- Oponerse , ya que continuaré oponiéndome a cualquiera de los muchos intentos de hacer que este proyecto se base más en Wikidata a través de la puerta trasera. DEsiegel tiene razón en este caso. Por muy malas que estén las cosas aquí, no son mejores allá. - Sitush ( charla ) 19:48, 13 de agosto de 2020 (UTC) Pero, espera, ¿la discusión parece estar en otra parte? - Sitush ( charla ) 19:49, 13 de agosto de 2020 (UTC)
- Soporte Por lo general, sospecho de la migración de cosas a WikiData, pero esto parece de bajo riesgo en términos de vandalismo. La mayoría de la gente reconocerá si el valor no es un color, e incluso si es sutil, debería ser obvio a partir de todas las imágenes cuáles son los colores correctos. Otros señalan que hay mejoras de contenido que se pueden realizar si se migra, por lo que parece una mejora neta. - Wug · a · po · des 19:57, 13 de agosto de 2020 (UTC)
- Soporte . Exactamente el tipo de datos para el que funciona mejor Wikidata. - Finnusertop ( charla ⋅ contribuciones ) 02:34, 14 de agosto de 2020 (UTC)
- Oponerse . Arriba, IagoOnsi afirma que "hay muchas formas de monitorear los datos y combatir el vandalismo". y agrega una consulta que se puede utilizar. Problemas; este es un paso adicional que se debe tomar (no integrado con la lista de seguimiento), en un sitio diferente, y da malos resultados. No solo no muestra qué se cambió o en qué diferencia (solo una fecha), sino que incluye cambios que no tienen nada que ver con el cambio de color. Por ejemplo, hay una entrada para el 24 de mayo de 2020 para los Portland Pilots; pero el único cambio en esa fecha es un bot que agrega una etiqueta china [3] . La consulta no filtra ni indica cambios de bot. Aparentemente, la consulta muestra páginas en las que se ha cambiado el color oficial en algún momento en el pasado y muestra la fecha del cambio más reciente en el elemento de Wikidata, sin importar cuál fue ese cambio. Lo que significa que, contrariamente a la afirmación, es imposible monitorear esto con esa consulta , ya que las entradas más recientes no mostrarán los cambios recientes de color, sino cualquier cambio reciente. No veo ninguna razón para cambiar un sistema de trabajo por uno más difícil de monitorear. Sería mejor, si hay una necesidad de otros lenguajes Wiki, escribir un bot que copie los cambios al módulo aquí, en Wikidata, manteniendo Wikidata sincronizado con nosotros. ¿Pero darle el control de esto a Wikidata? No, gracias. Fram ( charla ) 11:51, 14 de agosto de 2020 (UTC)
- @ Fram : Disculpas por ese problema con la consulta; No me di cuenta de eso. Sin embargo, el enfoque de hacer que un bot actualice una lista con una consulta aún funcionaría según lo previsto. Si tuviéramos un bot que actualizara una lista almacenada localmente con los resultados de esta consulta todos los días / horas / lo que sea, entonces sería fácil monitorear los cambios agregando la página de la lista a su lista de observación. La página de la lista solo se actualizará cuando se cambie un color. - Iago Qnsi ( charla ) 04:46, 18 de agosto de 2020 (UTC)
- Oponerse según DES. y Fram. Sugiera a alguien de Wikidata que haga una copia de este material y lo publique allí para usarlo en otras wikipedias si lo desea. Pero cero beneficios para en-WP al migrar nuestro propio alojamiento de estos datos y un riesgo distinto de cero en términos de menor capacidad de edición por parte de los contribuyentes locales. - Euryalus ( charla ) 12:10, 14 de agosto de 2020 (UTC)
- Oponerse en la práctica. Es una idea noble que podría funcionar bien si Wikidata tuviera tantos ojos en ella como enwiki. Sin embargo, es muy tentador cambiar el esquema de color del rival a caca y vómito, y un editor casual que se da cuenta puede no encontrar el camino a través del laberinto de código y datos hasta la fuente del problema. mw: Las plantillas y módulos multilingües pueden ser una buena alternativa. Certes ( charla ) 12:40, 14 de agosto de 2020 (UTC)
- ¿Por qué las plantillas multilingües en MediaWiki.org serían menos propensas al vandalismo que las declaraciones en Wikidata? * Pppery * ha comenzado ... 13:52, 14 de agosto de 2020 (UTC)
- Buena pregunta. Quizás sean más difíciles de encontrar y editar, y estarían en la lista de seguimiento del codificador. Si mw: es propenso al vandalismo, entonces deberíamos dejar las cosas como están. Certes ( charla ) 13:58, 14 de agosto de 2020 (UTC)
- (ec) Supongo que, a diferencia de lo que es gratis para todos los Wikidata, la intención es hacer que esas plantillas multilingües solo sean editables por un grupo comparable a nuestros editores de plantillas (pero obviamente no restringido a los editores enwiki). Si no es así, esta no es una solución, por supuesto. Fram ( charla ) 14:00, 14 de agosto de 2020 (UTC)
- Probablemente no sea la mejor persona para responder esto porque me opongo firmemente a las Plantillas y Módulos Multilingües por razones no relacionadas con su propensión al vandalismo (que expliqué mejor en mw: Plantillas globales / Discusión / oposición ), pero no estoy al tanto de cualquier plan establecido para restringir quién puede editarlos. Además, las plantillas multilingües no triviales a menudo dependen de los datos tabulares de Commons , que de la misma manera podrían necesitar protección para evitar el vandalismo. * Pppery * ha comenzado ... 14:39, 14 de agosto de 2020 (UTC)
- Parece que ese proyecto ha pasado al uso de una herramienta en lugar de un bot , lo que evita la preocupación por el vandalismo en las propias plantillas. Todavía existe la preocupación, probablemente más importante, sobre el vandalismo a los conjuntos de datos de Commons que usa la plantilla y, por supuesto, mi preocupación independiente sobre la perpetuación del exceso de código. * Pppery * ha comenzado ... 16:24, 14 de agosto de 2020 (UTC)
- ¿Por qué las plantillas multilingües en MediaWiki.org serían menos propensas al vandalismo que las declaraciones en Wikidata? * Pppery * ha comenzado ... 13:52, 14 de agosto de 2020 (UTC)
- Soporte , según GreenC, Mike y otros. Reh man 13:26, 14 de agosto de 2020 (UTC)
- Oponerse a esto parece mucho una solución en busca de un problema, ya que, como dice DESiegel, Wikidata podría importar datos del módulo de Wikipedia en inglés y por lo tanto ayudar a otras wikis incluso si esta propuesta falla. * Pppery * ha comenzado ... 13:52, 14 de agosto de 2020 (UTC)
- @ Pppery : Es bastante fácil que un bot importe los datos una vez, pero es difícil mantenerlos sincronizados a medida que pasa el tiempo. Cualquier nueva edición en enwiki debe ser reimportada, ya sea manualmente o por un bot que se ejecuta periódicamente (pero no hay una manera fácil para que un usuario típico de Wikidata esté seguro de que dicho bot todavía está en funcionamiento). Y si se realizan nuevas ediciones en Wikidata, se crea un conflicto que un bot no puede resolver. El efecto general es que cualquiera que use los datos de color a través de Wikidata obtendrá una versión inferior o no confiable. - Iago Qnsi ( charla ) 05:14, 18 de agosto de 2020 (UTC)
- Opónganse por Fram, Certes, Euryalus y Pppery. El objetivo de crear esto en primer lugar fue tener todos los datos de color recopilados en una ubicación centralizada. Si WD quiere hacer una copia de esto para ayudar a otros wikis, está bien, pero distribuir estos datos en cientos de páginas es literalmente lo que teníamos antes de que se creara este módulo. Nadie quiere volver a ese caos. Ejgreen77 ( charla ) 07:37, 16 de agosto de 2020 (UTC)
- @ Ejgreen77 : Esto no crearía un caos como el que existía en los días previos al módulo. El problema que solíamos tener es que los colores se almacenaban en docenas de artículos y tenían que sincronizarse manualmente. En Wikidata, al igual que en el módulo, solo se almacenarán en un lugar: el elemento del equipo. Todas las docenas de artículos sobre, digamos, los equipos de Duke Blue Devils sacarán los colores de la escuela de Duke Blue Devils (Q2907160) . Y es fácil consultar Wikidata para mostrar todos los colores en una página, como en esta consulta . - Iago Qnsi ( charla ) 05:01, 18 de agosto de 2020 (UTC)
- Aun así, todavía hay cientos de entradas en el módulo actualmente, por lo que todas esas entradas se almacenarán en su propia ubicación separada. El objetivo de crear esto en primer lugar fue almacenar todos los datos en una ubicación centralizada para que sea fácil de monitorear. Ejgreen77 ( charla ) 10:42, 26 de agosto de 2020 (UTC)
- @ Ejgreen77 : Podemos hacer que un bot actualice una página con los resultados de mi consulta anterior, de modo que haya una ubicación centralizada para facilitar el seguimiento. - Iago Qnsi ( charla ) 20:44, 27 de agosto de 2020 (UTC)
- Aun así, todavía hay cientos de entradas en el módulo actualmente, por lo que todas esas entradas se almacenarán en su propia ubicación separada. El objetivo de crear esto en primer lugar fue almacenar todos los datos en una ubicación centralizada para que sea fácil de monitorear. Ejgreen77 ( charla ) 10:42, 26 de agosto de 2020 (UTC)
- @ Ejgreen77 : Esto no crearía un caos como el que existía en los días previos al módulo. El problema que solíamos tener es que los colores se almacenaban en docenas de artículos y tenían que sincronizarse manualmente. En Wikidata, al igual que en el módulo, solo se almacenarán en un lugar: el elemento del equipo. Todas las docenas de artículos sobre, digamos, los equipos de Duke Blue Devils sacarán los colores de la escuela de Duke Blue Devils (Q2907160) . Y es fácil consultar Wikidata para mostrar todos los colores en una página, como en esta consulta . - Iago Qnsi ( charla ) 05:01, 18 de agosto de 2020 (UTC)
- Oponerse Si bien puede haber algunos usos válidos de Wikidata para almacenar información para su uso en Wikipedia, cada vez es más evidente que ya no se puede confiar en que mantenga los datos en una estructura utilizable. Es mejor guardar esta recopilación de datos relacionados en una única ubicación bajo el control de enwiki. - RexxS ( charla ) 18:42, 16 de agosto de 2020 (UTC)
- @ RexxS : Además de nuestro desacuerdo sobre el tema del estilo de las citas, no he visto ninguna discusión sobre la estructura de los datos. En la página de discusión del módulo, mostré cómo esperaba que se estructuraran los datos con un ejemplo : wikidata: Q2892868 # P6364 . Doy la bienvenida a las críticas, pero todavía no he visto ninguna. Saludos, Iago Qnsi ( charla ) 20:38, 27 de agosto de 2020 (UTC)
- @ Mike Christie y Johnbod : Ambos citaron el comentario de RexxS anterior como su razón para oponerse a la propuesta. Tengo curiosidad por saber qué partes de la estructura de Wikidata encuentras que no son utilizables. ¿Es el estilo de cita las preocupaciones que RexxS planteó anteriormente en la discusión, o es algo más? Nadie más ha intervenido en mí y en el hilo de estilo de citas de RexxS, por lo que no tengo ningún sentido de la opinión de la comunidad en general. Gracias, Iago Qnsi ( charla ) 20:38, 27 de agosto de 2020 (UTC)
- Mike dijo "según muchos de los comentarios anteriores; RexxS lo resume bien" y yo dije "según RexxS y otros". Creo que el resumen de RexxS es lo suficientemente claro y hay muchos puntos que otros han hecho. Johnbod ( charla ) 21:16, 27 de agosto de 2020 (UTC)
- Para mí, el punto clave que planteó RexxS es
Cada vez es más evidente que ya no se puede confiar en que mantendrá los datos en una estructura utilizable
. Actualizar descripciones breves es un gran uso de los recursos de enwiki que podrían dirigirse mejor a otros lugares, pero debe hacerse porque el vandalismo a las descripciones de Wikidata correspondientes es, prácticamente hablando, invisible para los observadores aquí. Eso me enfureció al usar Wikidata para cualquier cosa que pudiera hacerse igualmente bien aquí. A menos que haya importantes beneficios obvios para la mudanza, no quiero que enwiki mueva la información a donde no se pueda monitorear y administrar (y proteger) localmente. Mike Christie ( charla - contribuciones - biblioteca ) 21:36, 27 de agosto de 2020 (UTC)
- Para mí, el punto clave que planteó RexxS es
- Mike dijo "según muchos de los comentarios anteriores; RexxS lo resume bien" y yo dije "según RexxS y otros". Creo que el resumen de RexxS es lo suficientemente claro y hay muchos puntos que otros han hecho. Johnbod ( charla ) 21:16, 27 de agosto de 2020 (UTC)
- Oponerse ahora Los defensores de esta idea son libres de copiar la información de color en Wikidata y desarrollar módulos para usar en otras Wikipedias. Después de seis meses de operación exitosa, esta propuesta podría ser considerada para enwiki. Sin embargo, hasta entonces, se sabe que tener toda la información en una página funciona y se sabe que resiste los errores sutiles y el vandalismo total. En enwiki, cualquiera puede proponer un cambio de color, pero solo los editores de plantillas pueden editar. En Wikidata, cualquier IP puede cambiar de color en cualquiera de las 1140 ubicaciones. Johnuniq ( charla ) 09:52, 18 de agosto de 2020 (UTC)
- @ Johnuniq : La política de protección de Wikidata dice que todos los elementos utilizados en más de 500 páginas deben estar semiprotegidos. Los colores de cada escuela se utilizan en varios cientos de páginas y, con la probable llegada de otros wikis que utilizan estos colores, es probable que se apruebe una solicitud de semiprotección si esta propuesta sucediera. - Iago Qnsi ( charla ) 20:59, 27 de agosto de 2020 (UTC)
- Cualquiera puede copiar todos los datos en Wikidata y configurar lo que sea necesario para que funcione en los artículos. Luego pruébelo en varias Wikipedias (no enwiki) y vea cómo funciona durante seis meses. Después de eso, regrese y haga una propuesta para usarlo aquí. Johnuniq ( charla ) 23:48, 27 de agosto de 2020 (UTC)
- @ Johnuniq : La política de protección de Wikidata dice que todos los elementos utilizados en más de 500 páginas deben estar semiprotegidos. Los colores de cada escuela se utilizan en varios cientos de páginas y, con la probable llegada de otros wikis que utilizan estos colores, es probable que se apruebe una solicitud de semiprotección si esta propuesta sucediera. - Iago Qnsi ( charla ) 20:59, 27 de agosto de 2020 (UTC)
- ¡Apoyo por todos los votos de apoyo! Anteriores. Recientemente comencé a interactuar con todo el aparato de colores universitarios, y es un truco horrible que requiere una solicitud de edición protegida por plantilla solo para agregar una escuela faltante. Este es un valor ideal para almacenar en Wikidata, donde puede estar disponible para todos los idiomas y otras personas que buscan usarlo. Con respecto al abuso, no veo a los vándalos que realmente quieran cambiar la Universidad de Foobar de rojo a azul o tener éxito en hacerlo fuera del radar. {{u | Sdkb }} charla 07:46, 24 de agosto de 2020 (UTC)
- Admita que este es un valor en una plantilla que un usuario actualmente no puede editar de la forma en que las plantillas se editan normalmente en Wikipedia. Tener que ir a https://en.wikipedia.org/wiki/Module:College_color/data para editar los datos es completamente contradictorio. ChristianKl ❪ ✉ ❫ 15:04, 26 de agosto de 2020 (UTC)
- Si tener que ir a otra página en Wikipedia es contradictorio ... ¿no sería MÁS contradictorio tener que ir a un SITIO WEB completamente diferente (Wikidata) para editar? Blueboar ( charla ) 16:41, 26 de agosto de 2020 (UTC)
- @ Blueboar : Usar un sitio hermano de Wikimedia no debería ser demasiado difícil; Los comunes no parecen hacer tropezar demasiado a la gente. Si puede navegar por la cadena actual de {{ lista de CBB }} -> {{ CollegePrimaryStyle }} -> Módulo: color universitario -> Módulo: color / datos universitarios , probablemente podrá calcular Wikidata también. - Iago Qnsi ( charla ) 17:32, 26 de agosto de 2020 (UTC)
- Si tener que ir a otra página en Wikipedia es contradictorio ... ¿no sería MÁS contradictorio tener que ir a un SITIO WEB completamente diferente (Wikidata) para editar? Blueboar ( charla ) 16:41, 26 de agosto de 2020 (UTC)
- Oponerse , según muchos de los comentarios anteriores; RexxS lo resume bien. Mike Christie ( charla - contribuciones - biblioteca ) 17:36, 26 de agosto de 2020 (UTC)
- Oponerse , según RexxS y otros. Johnbod ( charla ) 18:06, 26 de agosto de 2020 (UTC)
- Comentario: he estado pensando por qué soy tan negativo sobre Wikidata. Y me he dado cuenta de que se trata de algunas razones muy simples. Primero, estoy orientado al texto y no a los datos. Simplemente no veo el mundo en términos de bits de datos que deben almacenarse y recuperarse. En segundo lugar (y más importante), soy una persona mayor, y se confunde fácilmente con todo este genio de la tecnología. Odio las plantillas (con todos sus parámetros y campos confusos) y las evito si puedo (por ejemplo, no uso plantillas de citas y aún hago todas mis citas a mano usando el formato texto ). Sin embargo, las plantillas me resultan muy sencillas en comparación con la edición de Wikidata. Lo intenté y rápidamente me di por vencido. Para decirlo sin rodeos ... siento que no soy capaz de editar wikidata. Cuando trasladamos cosas a Wikidata, quedan fuera de mi alcance como editor. Si tuviera que editar información extraída de Wikidata, NO PODRÍA hacerlo. Demasiado para "cualquiera puede editar". Blueboar ( charla ) 21:53, 27 de agosto de 2020 (UTC)
- Mi opinión es que la discusión de la cita anterior es en gran medida una pista falsa. Esa es una cuestión de implementación y estoy bastante seguro de que Trappist si nadie más pudiera proporcionar una cita funcional en CS1 o CS2 para los datos de referencia relacionados con cada color (y puedo elegir al menos otro usuario que podría hacerlo como él básicamente ya lo hice con otra plantilla).
Tengo al menos uno o dos intereses de discusión, el primero de los cuales es la cuestión de la implementación de los colores. Desde la memoria (móvil> yo), el módulo de colores universitarios no siempre proporciona colores verdaderos en aras de la accesibilidad y poder garantizar que los colores de frente y fondo cumplan con el cumplimiento de AA (o, a veces, agregamos colores en el tema escolar en particular que moderan esta pregunta pero que no son oficiales). Estos no son datos que Wikidata debería querer tomar y ciertamente no querría imponérselos. ¿Cómo propondría trabajar en torno a eso (asumiendo que mi pregunta no está fuera de lugar)?
Mi segundo interés se refiere a no usarlo en la página principal de la escuela (navboxes, entre otros), lo que a veces puede aumentar el costo de las operaciones. ¿Tiene una implementación en mente que solucione eso?
Dado el uso en navboxes, no estoy seguro de si estos son datos que deberíamos usar de Wikidata. Es casi seguro que se trata de datos en los que estarían interesados (pendiente q1) y, por lo tanto, mover / copiar los datos allí sin duda sería apreciado. - Izno ( charla ) 21:57, 27 de agosto de 2020 (UTC)
- @ Izno : ¡ Buenas preguntas! No sabía que ninguno de los colores de este módulo no era oficial. ¿Cómo se eligen estos colores no oficiales? Si se derivan sistemáticamente de los colores oficiales, entonces imagino que podríamos almacenar solo los colores oficiales en Wikidata, y hacer que nuestro módulo en Wikipedia derive los colores accesibles a medida que los recupera. Si se eligen de otra manera, es posible que deseemos encontrar algún esquema para almacenarlos, tal vez utilizando la naturaleza de la declaración (P5102) para distinguir los colores oficiales y no oficiales. Creo que sería útil tener estos colores no oficiales almacenados en Wikidata también; El cumplimiento de AA es algo en lo que todos los proyectos de Wikimedia estarían interesados, no solo en nosotros. Es solo cuestión de encontrar una buena forma de delimitarlos de los colores oficiales.
- En cuanto al tema de las costosas operaciones, no tenía en mente una implementación en particular. Un método que sería bastante fácil sería hacer que un bot actualice una página local cada hora con los resultados de una consulta para todos los colores de la universidad, y luego hacer que la plantilla / módulo extraiga el color desde allí en lugar de directamente desde Wikidata. Esa no sería una gran solución a largo plazo si expandiéramos esto para que se use para más que solo deportes universitarios, pero tal vez haya otras formas de almacenar en caché de manera eficiente esto que no conozco, o tal vez es algo que podría plantearse con los desarrolladores de Wikidata Lua.
- También podríamos permitir que se utilice aquí una única consulta costosa. La mayoría de los artículos solo usan colores de una sola escuela, por lo que no sería un gran problema. Hay algunos artículos, como Atlantic Coast Conference, que utilizan colores de muchas escuelas, y nos gustaría tener una mejor solución para ellos. Quizás podríamos hacer que un bot use una consulta SPARQL para actualizar artículos que usan los colores de muchas escuelas cada hora. Pero a corto plazo, no creo que haya páginas que usen suficientes colores de escuelas diferentes para alcanzar el límite de funciones costosas, por lo que no necesariamente tenemos que tener una solución finalizada para esto todavía. - Iago Qnsi ( charla ) 23:42, 27 de agosto de 2020 (UTC)
- Oponerse por ahora por Johnuniq . Estoy dispuesto a reconsiderarlo después de verlo demostrado que funciona mejor que el sistema actual en la práctica, incluida la facilidad de uso para personas que no están familiarizadas con ninguno de los sistemas, menor carga de trabajo para los editores, cumplimiento con MoS y resistencia al vandalismo. · · · Peter Southwood (charla) : 13:55, 28 de agosto de 2020 (UTC)
Agregar calificaciones de IMDb y Rotten Tomatoes al cuadro de información del artículo (siempre que sea posible)
Actualmente, ningún artículo (o muy pocos) sobre películas, cortometrajes, series web, etc. en Wikipedia contiene calificaciones proporcionadas por fuentes destacadas como IMDb y Rotten Tomatoes en el Infobox del artículo. Mucha gente visita Wikipedia para obtener toda la información posible sobre la película, incluida su recepción crítica. La mayoría de los artículos escritos sobre cualquier sitio web contienen su clasificación de Alexa. Si tales artículos pueden contener la clasificación de Alexa, entonces creo que los artículos sobre películas deben contener sus calificaciones de IMDb y Rotten Tomatoes. Soukarya ( charla ) 18:11, 17 de agosto de 2020 (UTC)
- Con el fin de mantener distintas discusiones separadas, he dividido este hilo en subsecciones a continuación. Coloque más comentarios en esas secciones. {{u | Sdkb }} charla 19:12, 17 de agosto de 2020 (UTC)
- El tema de esta discusión se ha editado para incluir la palabra 'Infobox' para evitar más confusiones con respecto a la propuesta. Soukarya ( charla ) 12:04, 18 de agosto de 2020 (UTC)
Encuesta: IMDb en el cuadro de información
- No creo que sea una buena idea porque son fuentes de datos generadas por el usuario que a menudo están sujetas a manipulación de bloques para que no se pueda confiar en ellas. No podemos controlar estas calificaciones, ni podemos incluir notas junto con nuestra inclusión de ellas (por ejemplo, "Se sabe que esta calificación ha sido manipulada") porque entonces solo incluimos datos no confiables .-- Jorm ( hablar ) 18:25, 17 de agosto de 2020 (UTC)
- @ Jorm : Acabo de crear subsecciones para organizar mejor este hilo y coloqué su comentario aquí. No dude en refactorizar si es necesario. {{u | Sdkb }} charla 19:18, 17 de agosto de 2020 (UTC)
- Hmm, siempre tomo estas calificaciones con una pizca de sal. Las calificaciones de IMDb son representativas de las personas que podrían molestarse en votar, mientras que las calificaciones de Rotten Tomatoes también son subjetivas. Es mejor ceñirse a las críticas de los principales críticos .-- ♦ Ian Ma c M ♦ (habla conmigo) 18:21, 17 de agosto de 2020 (UTC)
- @ Ianmacm : Acabo de crear subsecciones para organizar mejor este hilo y coloqué su comentario aquí. No dude en refactorizar si es necesario. {{u | Sdkb }} charla 19:18, 17 de agosto de 2020 (UTC)
- Oponerse , ya que esos pueden y han sido objeto de manipulación. Vea, por ejemplo, que los Trolls del Washington Post están haciendo todo lo posible para derribar el reinicio de los 'Cazafantasmas' y el análisis de FiveThirtyEight sobre cómo las calificaciones de IMDb están sesgadas sistemáticamente hacia las preferencias de los hombres. {{u | Sdkb }} charla 19:12, 17 de agosto de 2020 (UTC)
- Oponerse a IMDB es un puntaje definido por el usuario y, por lo tanto, susceptible de revisión de bombas y otros factores y, por lo tanto, no debe considerarse una medida confiable. (pero ese es solo un problema ...) Las puntuaciones basadas en reseñas de usuarios normalmente no se incluyen en ningún artículo a menos que sean notadas por terceros (como bombas de reseñas) en primer lugar. - M asem ( t ) 19:38, 17 de agosto de 2020 (UTC)
- Oponerse por discusiones pasadas en el proyecto de película. MarnetteD | Charla 20:00, 17 de agosto de 2020 (UTC)
- Oponerse Incluir calificaciones de IMDB en el cuadro de información violaría MOS: FILM # Audience_response que dice " No incluya calificaciones de usuarios enviadas a sitios web como Internet Movie Database, Metacritic o Rotten Tomatoes, ya que son vulnerables a la acumulación de votos y al sesgo demográfico " . Betty Logan ( charla ) 23:18, 17 de agosto de 2020 (UTC)
- Oponerse Muy fácil de manipular . Ese enlace muestra uno de mis videos favoritos de YouTube de todos los tiempos ... pero no lo sabrías mirando IMDb, ya que pensarías que es una de las películas mejor calificadas en IMDb de todos los tiempos, ignorando el hecho de que su puntaje es como resultado de un grupo de observadores de YouTube que manipularon la partitura. Además, poner IMDb en el cuadro de información solo alentaría a la gente a usarlo para otras cosas, contra las que ya estamos tratando de luchar, ya que no es un RS. CaptainEek edita Ho Cap'n! ⚓ 21:36, 19 de agosto de 2020 (UTC)
- Oponerse a IMDb generalmente no es una fuente confiable y se debe desaconsejar su uso, excepto en circunstancias muy limitadas. Cullen 328 Vamos a discutirlo 21:40, 19 de agosto de 2020 (UTC)
- Oponerse a una fuente poco confiable. Su uso en el espacio de artículos debe desaconsejarse, no fomentarse. - Malcolmxl5 ( charla ) 14:03, 25 de agosto de 2020 (UTC)
- Absolutamente OPONERSE : por todo lo anterior. ¿Puede alguien cerrar esto SNOW? GenQuest "Talk to Me" 18:16, 30 de agosto de 2020 (UTC)
Encuesta: agregaciones de opiniones críticas en el cuadro de información
Por ejemplo, tomates podridos , metacrítico
- Apoye la adición de una de estas puntuaciones, ya que es información pertinente para los lectores. {{u | Sdkb }} charla 19:12, 17 de agosto de 2020 (UTC)
- Oponerse Al menos viniendo de los videojuegos, hay demasiadas ocasiones en las que el simple hecho de presentar el puntaje total por sí mismo es un nombre inapropiado de cómo se debe tomar la recepción del juego. La partitura debe presentarse junto con otras revisiones y comentarios para darle perspectiva. (Un caso reciente es The Last of Us II ). Estoy seguro de que se puede decir lo mismo de las películas; una película criticada puede ser un favor de la audiencia que no será capturado por una sola partitura. - M asem ( t ) 19:40, 17 de agosto de 2020 (UTC)
- Oponerse por discusiones pasadas en el proyecto de película. MarnetteD | Charla 20:00, 17 de agosto de 2020 (UTC)
- Oponerse La caja de información es para hechos. Rotten Tomatoes y Metacritic son agregadores de reseñas, por lo que sus puntajes vienen con las "subjetividades" de las cuales los críticos son aprobados y contados por ellos, además de la subjetividad propia de cada reseña. Poner una o ambas puntuaciones en el cuadro de información daría una calidad de hecho que no deberían tener. El Millo ( charla ) 20:07, 17 de agosto de 2020 (UTC)
- Oponerme Estoy de acuerdo con El Millo en que es mejor reservar la caja de información para información fáctica. La siguiente pregunta de esta encuesta (es decir, ¿deberíamos usar RT o MC en el cuadro de información?) Socava el argumento a favor de incluir un agregador. Según WP: AGG, no existe una autoridad única sobre recepción crítica. A veces, RT y MC pueden llegar a conclusiones diferentes debido a sus diferentes metodologías y al muestreo de diferentes revisiones. Además, estos agregadores no funcionan particularmente bien para películas extranjeras (el tamaño de la muestra suele ser demasiado pequeño) o películas más antiguas (las reseñas a menudo están dispersas, lo que significa una mezcla de reseñas contemporáneas y revisionistas; lo ideal es comparar la recepción inicial con la hoy en día representa una película clásica). Betty Logan ( charla ) 23:25, 17 de agosto de 2020 (UTC)
- Oponerse Deberíamos estar resumiendo las evaluaciones de los críticos de cine profesionales en lugar de permitir que los agregadores resuman por nosotros. Cullen 328 Vamos a discutirlo 21:43, 19 de agosto de 2020 (UTC)
- OPONERSE : Los InfoBoxes son para hechos, y no necesariamente todos los hechos. De hecho, los InfoBoxes son opcionales. Por CREEP . GenQuest "Talk to Me" 18:19, 30 de agosto de 2020 (UTC)
Encuesta: Rotten Tomatoes frente a Metacritic para infobox
Si decidimos anteriormente incluir una agregación de reseñas de críticos , ¿qué servicio deberíamos incluir?
- No estoy listo para hacer un voto en negrita sobre esto, pero los factores a sopesar entre ellos son que Rotten Tomatoes es más popular, pero Metacritic hace un mejor uso de las estadísticas . {{u | Sdkb }} charla 19:12, 17 de agosto de 2020 (UTC)
¡Votos perdidos! |
---|
|
Discusión General
Tenga en cuenta que ya existen políticas y pautas para esto. Consulte Wikipedia: Manual de estilo / Film # Respuesta crítica y MOS: TVRECEPTION , así como este ensayo Wikipedia: Review aggregators . Es posible que el OP no sepa que un gran porcentaje de los artículos cinematográficos incluyen calificaciones de RT. IMDb no debe incluirse, ya que son simplemente una encuesta de fans y no tienen ningún valor crítico o académico. MarnetteD | Charla 19:16, 17 de agosto de 2020 (UTC)
- @ MarnetteD : Creo que el OP está preguntando principalmente sobre infoboxes. Acabo de refactorizar las subsecciones para hacerlo explícito. Perdón por hacer una refactorización tan agresiva aquí; Estoy tratando de poner esto en una ruta enfocada / definida antes de que se aleje demasiado del suelo. Soukarya , avíseme si tiene algún problema con él. {{u | Sdkb }} charla 19:26, 17 de agosto de 2020 (UTC)
En ningún momento de la declaración del OP se utiliza la palabra infobox.Si eso es lo que quieren decir, tenga en cuenta que esto se ha discutido en numerosas ocasiones en el proyecto de película y ha sido rechazado. Quizás Betty Logan o Erik (que tienen mejores recuerdos que yo) puedan dirigirlo a las discusiones archivadas. MarnetteD | Charla 19:32, 17 de agosto de 2020 (UTC)- De hecho, el encabezado del hilo dice claramente "Agregar calificaciones de IMDb y Rotten Tomatoes a los artículos (siempre que sea posible) (énfasis mío),
por lo que refactorizar los subtítulos para agregar la palabra" infobox "solo confunde el problema.Sugeriría cerrar este hilo ya que (de nuevo) ya existen políticas al respecto. MarnetteD | Charla 19:43, 17 de agosto de 2020 (UTC)"Infobox"
se agrega aquí . Parada de autobús ( conversación ) 19:48, 17 de agosto de 2020 (UTC)- Gracias por corregir mi mala interpretación de la publicación Parada de autobús. Disculpas por el error. El título del hilo es parte de la confusión. No encontré las discusiones pasadas todavía, pero encontré este WP: FILMRATING que también es parte de WP: MOSFILM . MarnetteD | Charla 19:54, 17 de agosto de 2020 (UTC)
- Aquí hay una charla de plantilla de discusión anterior : Infobox film / Archive 24 # Rotten Tomatoes . Otro problema es que una vez que hace espacio para un sitio web agregado, debe seguir agregándolos, lo que conduce a la hinchazón del infobox, algo que siempre debe evitarse. MarnetteD | Charla 19:59, 17 de agosto de 2020 (UTC)
- Si llegamos a algún consenso sobre la posibilidad de agregar calificaciones al cuadro de información, entonces podemos continuar nuestra discusión sobre qué sitios web agregados podrían ser los más confiables y ceñirnos a alguna política que permita calificaciones de solo unos pocos agregadores que serían reconocidos por la mayoría. de los editores de Wikipedia. Soukarya ( charla ) 12:17, 18 de agosto de 2020 (UTC)
- Disculpe las molestias que le causaron y gracias por resaltar este problema con el título del hilo, que he editado para que el título sea más informativo. Soukarya ( charla ) 12:17, 18 de agosto de 2020 (UTC)
- Aquí hay una charla de plantilla de discusión anterior : Infobox film / Archive 24 # Rotten Tomatoes . Otro problema es que una vez que hace espacio para un sitio web agregado, debe seguir agregándolos, lo que conduce a la hinchazón del infobox, algo que siempre debe evitarse. MarnetteD | Charla 19:59, 17 de agosto de 2020 (UTC)
- Gracias por corregir mi mala interpretación de la publicación Parada de autobús. Disculpas por el error. El título del hilo es parte de la confusión. No encontré las discusiones pasadas todavía, pero encontré este WP: FILMRATING que también es parte de WP: MOSFILM . MarnetteD | Charla 19:54, 17 de agosto de 2020 (UTC)
- De hecho, el encabezado del hilo dice claramente "Agregar calificaciones de IMDb y Rotten Tomatoes a los artículos (siempre que sea posible) (énfasis mío),
- Parece que este hilo no va a ninguna parte, así que estoy de acuerdo con que esté cerrado por SNOW. Es posible que en algún momento queramos discutir RT vs. Metacritic en el cuerpo y, como siempre, hay mucho trabajo por hacer para mejorar la documentación del consenso pasado. {{u | Sdkb }} charla 05:52, 18 de agosto de 2020 (UTC)
- OTOH, varios de estos, especialmente IMDb, se agregan como == Enlaces externos == en miles de artículos. Prefiero verlos en una barra de pie de página pequeña (!), Similar a Plantilla: Recursos médicos (que normalmente ocupa una sola línea en una pantalla de computadora portátil no muy grande, porque si bien hay muchas opciones, solo unas pocas se aplican a cualquier tema en particular). Pregunté en WP: BOTREQ sobre esto, y si queríamos construir algo que proporcionara estos enlaces externos, pero ocupara menos espacio que enumerar cada uno como un elemento separado en una lista con viñetas, pensaron que la mayoría de los artículos podrían convertirse a los más pequeños. formato por bot. WhatamIdoing ( charla ) 03:51, 20 de agosto de 2020 (UTC)
- Ciertamente apoyaría esta ^^^ como propuesta. Saludos, GenQuest "Talk to Me" 18:21, 30 de agosto de 2020 (UTC)
Minimice automáticamente las etiquetas de borrador para Visual Editor como lo hacemos con las etiquetas de limpieza / AfD
He tenido malas experiencias de usuario (UX) mientras miraba artículos en borrador a través del Editor visual, que uso casi exclusivamente.
En lugar de ver el artículo en sí, tendrán plantillas enormes por las que tendrá que desplazarse cada vez que desee ver, y mucho menos editar, el artículo.
Por el contrario, cuando miro un artículo en el espacio principal que tiene una etiqueta de limpieza o AfD, es discreto y minimizado, y se expande cuando haces clic en él. Creo que las diversas etiquetas de Borrador también deberían minimizarse automáticamente hasta que se haga clic en ellas. Creo que los usuarios más nuevos, especialmente, se sentirían más cómodos si continuaran mejorando el artículo si no hubiera etiquetas de rechazo masivas encima que tuvieran que atravesar en cada instancia. Gleeanon409 ( charla ) 13:19, 18 de agosto de 2020 (UTC)
- Gleeanon409 , me suena razonable. No estoy seguro de cuáles son los mecanismos técnicos en juego. {{u | Sdkb }} charla 19:06, 18 de agosto de 2020 (UTC)
- Gleeanon409 , ¿podría darme un par de enlaces a un borrador del "peor de los casos" y un artículo contrastante con etiquetas de limpieza o AFD? Puedo presentar un informe de error si el problema está en el VisualEditor en lugar de en el diseño de la plantilla. Whatamidoing (WMF) ( charla ) 04:10, 20 de agosto de 2020 (UTC)
- @ Whatamidoing (WMF) : , Dumb Mostrar vs. Proyecto: Tor'i Brooks . Gleeanon409 ( charla ) 07:26, 20 de agosto de 2020 (UTC)
- Gleeanon409 , ¿podría darme un par de enlaces a un borrador del "peor de los casos" y un artículo contrastante con etiquetas de limpieza o AFD? Puedo presentar un informe de error si el problema está en el VisualEditor en lugar de en el diseño de la plantilla. Whatamidoing (WMF) ( charla ) 04:10, 20 de agosto de 2020 (UTC)
¿Qué debe suceder para que esto suceda? Gleeanon409 ( charla ) 12:46, 24 de agosto de 2020 (UTC)
- @ Gleeanon409 , parece que el problema es que la caja AFC (muy grande) tiene varias secciones colapsadas. Cuando se expanden, todo es enorme. Esto no se puede arreglar en el editor visual, que trata de la misma manera todo el contenido que se puede contraer y, específicamente, los descompone (por ejemplo, para que pueda asegurarse de haber agregado el cuadro de navegación correcto). Pero podría ser posible arreglar esto en la plantilla, usando algo como {{ si vista previa }} para mantener el contenido en estado contraído. @ Evad37 , ¿cree que podría funcionar? Whatamidoing (WMF) ( charla ) 17:28, 24 de agosto de 2020 (UTC)
- @ Whatamidoing (WMF) : Plantilla: si la vista previa no funciona con el editor visual, por ejemplo, https://en.wikipedia.org/w/index.php?title=Template:If_preview/doc&veaction=edit muestra "cuando se guarda" valores en la columna de ejemplos, no los valores "cuando se obtiene una vista previa". - Evad 37 [ charla ] 01:16, 27 de agosto de 2020 (UTC)
- Bueno, ahí va esa idea. ¿Quizás deberíamos llevar esto a WP: VPT ? Whatamidoing (WMF) ( charla ) 01:35, 2 de septiembre de 2020 (UTC)
- @ Whatamidoing (WMF) : Plantilla: si la vista previa no funciona con el editor visual, por ejemplo, https://en.wikipedia.org/w/index.php?title=Template:If_preview/doc&veaction=edit muestra "cuando se guarda" valores en la columna de ejemplos, no los valores "cuando se obtiene una vista previa". - Evad 37 [ charla ] 01:16, 27 de agosto de 2020 (UTC)
Desindexar páginas de conversación
¿Deberíamos desindexar todas las páginas de discusión en Wikipedia de los motores de búsqueda? Esto se produce aproximadamente un mes después de una discusión similar (no RfC) sobre los posibles beneficios y desventajas de desindexar algunos espacios de nombres sin contenido. A a s i m 17:23, 19 de agosto de 2020 (UTC)
Para dar un poco de contexto: un día estaba navegando por el motor de búsqueda de mi elección y terminé encontrando una imagen que solo estaba incluida en una página de discusión. La razón por la que hago esta propuesta es (1) no queremos que aparezca información inexacta (y potencialmente difamatoria) sobre un tema (ya sea una persona, empresa, organización o temas médicos) en los resultados de búsqueda y (2) páginas de discusión no proporcionan ayuda alguna a los lectores [aclaración: lo que quiero decir es que no ayudan a los lectores a buscar un tema en Google o Bing]. Los vería como causantes de más confusión (incluso con el descargo de responsabilidad) como, y me voy a citar aquí, las personas que comprueban la fuente de [imágenes en las páginas de discusión] se confundirán al ver lo que parece un tipo de foro extraño en el que solo algunas personas pueden comentar en lugar del artículo tradicional de Wikipedia.
Por estas dos razones principales, comencé este RfC. A a s i m 17:29, 19 de agosto de 2020 (UTC)
Notas técnicas
Como esto se dirige ahora solo espacio de nombres: 1 ( "Discusión:") la implementación técnica sería estableciendo (noindex,follow)
en $wgNamespaceRobotPolicies
. Esto se puede hacer con una solicitud de fabricador como en phab: T104797 , dicha solicitud debe incluir un enlace permanente a una discusión comunitaria cerrada exitosa. - Charla xaosflux 23:27, 19 de agosto de 2020 (UTC)
Una decisión secundaria que se puede tomar es si se __INDEX__
debe permitir el uso de para permitir intencionalmente la indexación página por página (esta es una actualización de $wmgExemptFromUserRobotsControlExtra
); de manera predeterminada, se permitiría el etiquetado manual para la indexación, pero también se puede prohibido si es necesario. Las páginas etiquetadas manualmente para indexar aparecerán en Categoría: páginas indexadas para seguimiento y revisión. - Charla xaosflux 23:27, 19 de agosto de 2020 (UTC)
En una nota relacionada, actualmente la mayoría de las páginas de discusión de BLP no están indexadas por tener una plantilla que incluye la directiva NOINDEX, como se puede ver en la Categoría: No páginas indexadas . - Charla xaosflux 23:30, 19 de agosto de 2020 (UTC)
- A continuación, es posible que algunos "archivos" de copiar y pegar páginas de discusión no se etiqueten así. Un bot puede ser adecuado para esta tarea si se desea. - Charla xaosflux 13:09, 20 de agosto de 2020 (UTC)
- La
la mayoría de las páginas de discusión de BLP no están indexadas por tener una plantilla que incluye la directiva NOINDEX
porque esas páginas de discusión incluyen Template: BLP , que contiene un__NOINDEX__
. Convencionalmente, no se usa directamente, sino que se realiza mediante uno o ambos de o . - Red rose64 🌹 ( charla ) 19:37, 20 de agosto de 2020 (UTC){{BLP}}
{{WikiProject Biography|living=yes}}
{{WikiProject banner shell|blp=yes|1=...}}
- La
- Algo que acabo de observar para una nueva página que creé es que, a pesar de que aún no figura en Google, ya que no se ha marcado en NPP, su página de discusión está en la lista. Definitivamente eso no es lo que queremos. {{u | Sdkb }} charla 23:49, 31 de agosto de 2020 (UTC)
Discusión (desindexación de páginas de discusión)
- Fuerte oposición : la herramienta de búsqueda de Wikipedia consume el 99% del tiempo para la búsqueda de debates específicos. Buscar en Google páginas de discusión es a menudo mucho más fácil y flexible que la búsqueda incorporada de MediaWiki y aceptar esta propuesta resultará en que sea mucho más difícil para mí y para muchos otros editores que usan Google y otros motores de búsqueda para encontrar páginas de discusión u otras discusiones, especialmente ya que es posible que muchos ni siquiera se den cuenta del cambio de indexación. Ed habla! 18:44, 19 de agosto de 2020 (UTC)
- Ed6767 , entiendo que la búsqueda de Wikipedia puede ser un poco poco intuitiva de usar para buscar una discusión específica. Acabo de votar por un MfD y me enteré de que la página nominada para su eliminación, antes del MfD, aparecía en los resultados de búsqueda al buscar el tema. Ver [4] . No creo que esto sea algo que queramos que vean los lectores. A a s i m 20:43, 19 de agosto de 2020 (UTC)
- @ Awesome Aasim : Para aclarar, ¿te refieres a (i) que Paul A. Bonacci estaba mostrando en Google; (ii) ese Talk: Paul A. Bonacci estaba mostrando; (iii) que Wikipedia: Miscelánea para supresión / Charla: ¿Paul A. Bonacci estaba mostrando? - Red rose64 🌹 ( charla ) 18:33, 20 de agosto de 2020 (UTC)
- Redrose64 , acabo de hacer una búsqueda en Google y, efectivamente , está la página de discusión . A a s i m 18:37, 20 de agosto de 2020 (UTC)
- @ Redrose64 : (ii). Saludos, Newyorkbrad ( charla ) 18:43, 20 de agosto de 2020 (UTC)
- Por plantilla: NOINDEX # Advertencias , los principales motores de búsqueda deben respetar la etiqueta, pero pueden pasar días o incluso semanas para que el contenido ya indexado se elimine de ellos. En este caso, la etiqueta se agregó hace menos de 24 horas. Idealmente, esa página de discusión debería haber sido etiquetada con varios años atrás. - Red rose64 🌹 ( charla ) 19:48, 20 de agosto de 2020 (UTC)
{{NOINDEX}}
{{WikiProject Biography|living=yes}}
- Por plantilla: NOINDEX # Advertencias , los principales motores de búsqueda deben respetar la etiqueta, pero pueden pasar días o incluso semanas para que el contenido ya indexado se elimine de ellos. En este caso, la etiqueta se agregó hace menos de 24 horas. Idealmente, esa página de discusión debería haber sido etiquetada con varios años atrás. - Red rose64 🌹 ( charla ) 19:48, 20 de agosto de 2020 (UTC)
- @ Awesome Aasim : Para aclarar, ¿te refieres a (i) que Paul A. Bonacci estaba mostrando en Google; (ii) ese Talk: Paul A. Bonacci estaba mostrando; (iii) que Wikipedia: Miscelánea para supresión / Charla: ¿Paul A. Bonacci estaba mostrando? - Red rose64 🌹 ( charla ) 18:33, 20 de agosto de 2020 (UTC)
- Ed6767 , entiendo que la búsqueda de Wikipedia puede ser un poco poco intuitiva de usar para buscar una discusión específica. Acabo de votar por un MfD y me enteré de que la página nominada para su eliminación, antes del MfD, aparecía en los resultados de búsqueda al buscar el tema. Ver [4] . No creo que esto sea algo que queramos que vean los lectores. A a s i m 20:43, 19 de agosto de 2020 (UTC)
No estoy de acuerdo con la afirmación de queAfligido tras la aclaración de que las páginas de discusión no proporcionan ayuda a los lectores que buscan información sobre un tema a través de motores de búsqueda externos. 22:03, 19 de agosto de 2020 (UTC) Como lector, normalmente consulto la página de discusión de un artículo si veo ciertas etiquetas de mantenimiento, principalmente NPOV. Y antes de comenzar a editar, a veces iba a la página de discusión para hacer preguntas como una ip para buscar claridad sobre un lenguaje confuso, por ejemplo. No estoy seguro de si ese segundo caso de uso descalifica mi experiencia, ya que la pregunta que hice técnicamente me convertiría en un editor en lugar de un lector , pero definitivamente encontré un beneficio al consultar discusiones anteriores sobre un tema con el que no estoy familiarizado. incluso si no tengo ninguna intención de editar la página.Las páginas de discusión no brindan ayuda alguna a los lectores
(énfasis en el original).
- No hay comentarios sobre la propuesta en sí, pero Usuario: Awesome Aasim , ¿cree que podría hacer un ping de cortesía a los otros diez editores involucrados en la discusión anterior que inició en esta página archivada hace menos de un mes? Puede que me equivoque, pero creo que esa es una práctica estándar para los proponentes de RFC. <3 Folly Mox ( charla ) 20:22, 19 de agosto de 2020 (UTC)
- Locura Mox , está bien. @ Ed6767 , Rmhermen , Þjarkur , TheDJ , Teratix , Orangemike , GenQuest , John M Wolfson , DGG , Phil Bridger y Schazjmd : ping de cortesía. A a s i m 20:31, 19 de agosto de 2020 (UTC)
- Folly Mox , para aclarar sobre la parte de " no ayuda ": las páginas de discusión son realmente beneficiosas solo para los editores que buscan mejorar el artículo. Muchos lectores no buscan fuentes de información en las páginas de discusión. No ayudarán a los lectores a buscar un tema. Debería haberlo dejado más claro en el contexto del RfC. A a s i m 20:33, 19 de agosto de 2020 (UTC)
- Agregué esa aclaración en el "contexto". A a s i m 20:54, 19 de agosto de 2020 (UTC)
- Concur : el contenido de basura en las páginas de discusión es mucho mayor, y las cosas que nunca permitiríamos que permanezcan en un artículo pueden simplemente estar allí en una página de discusión, como el proverbial "t ** d in a punchbowl", listo para ser encontrado. por un buscador de información poco sofisticado. - Orange Mike | Charla 21:08, 19 de agosto de 2020 (UTC)
- ? Awesome Aasim, el espacio de nombres "Talk:" es bastante fácil de identificar en su propuesta, pero en cuanto a "otras discusiones", ¿cómo las define? Por ejemplo, ¿también está proponiendo que toda la bomba de la aldea no sea indexable? - Charla xaosflux 22:47, 19 de agosto de 2020 (UTC)
- Xaosflux Hmmm ... por ahora, supongo que hagamos páginas de discusión. Actualizaré el encabezado y la pregunta para aclarar eso. A a s i m 23:26, 19 de agosto de 2020 (UTC)
- El soporte no es apropiado para Google, y creo que la afirmación de que el sistema interno es "demasiado difícil", etc., es una tontería; muchos lugares de discusión (como los tablones de anuncios de Village Pumps y Administrators, etc.) tienen una herramienta de búsqueda de archivos, y para el resto hay Special: PrefixIndex . Cualquiera que desafortunadamente caiga en esas grietas puede, en última instancia, simplemente "lidiar con eso", para ser franco. - John M Wolfson ( charla • contribuciones ) 23:01, 19 de agosto de 2020 (UTC)
- Soporte para páginas de discusión por discusión previa. Oponte a cualquier cosa más allá de eso por ahora. - Wug · a · po · des 23:09, 19 de agosto de 2020 (UTC)
- Soporte honestamente asombrado de que esos estuvieran indexados para empezar. Headbomb { t · c · p · b } 23:14, 19 de agosto de 2020 (UTC)
- Soporte , también para todos los espacios de nombres * _talk:. También me sorprende que estas páginas estén indexadas. Aunque están disponibles públicamente, corresponden a discusiones entre bastidores que la mayoría de los sitios web mantendrían en privado y que retienen material que rápidamente eliminaríamos de los artículos. Los lectores casi siempre buscan un artículo y no quieren ser desviados a la discusión sobre cómo se hizo. Certes ( charla ) 00:43, 20 de agosto de 2020 (UTC)
- Soporte : de alguna manera pensé que este ya era el caso. Sé que el espacio de usuario no está indexado, pero en general no creo que sea necesario indexar los espacios de nombres de conversación de forma predeterminada (pero podría haber un buen caso para las excepciones caso por caso). - Hablar de las rododendritas \\ 01:32, 20 de agosto de 2020 (UTC)
- Oponerse (de la discusión anterior):
Creo que los efectos negativos de indexar las páginas de discusión son demasiado leves para justificar el cambio de la práctica habitual ... Esperaría que los usuarios que encuentren páginas de discusión en sus resultados de búsqueda comprendan su naturaleza como centros de discusión, dado el prefijo claro en sus títulos, y ajustar las expectativas de su contenido en consecuencia. El problema es cuando los motores de búsqueda presentan el contenido de las páginas de discusión de manera engañosa, como en la búsqueda Bing de Aasim. Bing, a diferencia de Google, no da el dominio de una imagen sin un mouseover, e incluso entonces, de manera ambigua, da la fuente del gráfico como "Wikipedia" (tienes que hacer clic para ver que es de una página de discusión). Esa es su responsabilidad de arreglar, no la nuestra. Si la fuente del gráfico se presenta de forma inequívoca, no habría ningún problema.
- Tera tix ₵ 03:14, 20 de agosto de 2020 (UTC)
- Otro problema fue el potencial negativo
impacto en los usuarios a los que no les gusta el motor de búsqueda de MediaWiki y prefieren navegar por los archivos de discusión a través de motores externos
, lo que, como sugiere el comentario de Ed6767, no es una práctica infrecuente. - Tera tix ₵ 03:19, 20 de agosto de 2020 (UTC) - Teratix no servirá para decir eso
[Es responsabilidad de Bing] arreglarlo, no nuestra
. Que algo pueda no ser nuestra responsabilidad no lo hace menos nuestro problema, especialmente si Bing no hace nada al respecto. No podemos controlar lo que hace Bing, pero podemos controlar lo que hacemos. Sus otros argumentos son sólidos (incluso si no estoy de acuerdo con ellos, vea arriba), pero solo quería señalar y refutar ese punto en particular. - John M Wolfson ( charla • contribuciones ) 03:57, 20 de agosto de 2020 (UTC)- ¿Sabemos con certeza que Bing no hará nada sobre el problema si alguien pregunta? - Tera tix ₵ 02:10, 21 de agosto de 2020 (UTC)
- Pueden o no, pero eso no significa que no debamos rechazar una buena propuesta basada única o parcialmente en lo que otros sitios web "deberían" o "no deberían" hacer con nuestras páginas (a menos, por supuesto, que ello implique una responsabilidad legal de su parte, pero estoy divagando) . - John M Wolfson ( charla • contribuciones ) 03:08, 21 de agosto de 2020 (UTC)
- No creo que sea una "buena propuesta por lo demás"; tendría serios impactos negativos en los editores que prefieren utilizar motores de búsqueda externos para navegar por las discusiones, como varios han atestiguado. - Tera tix ₵ 03:20, 21 de agosto de 2020 (UTC)
- Pueden o no, pero eso no significa que no debamos rechazar una buena propuesta basada única o parcialmente en lo que otros sitios web "deberían" o "no deberían" hacer con nuestras páginas (a menos, por supuesto, que ello implique una responsabilidad legal de su parte, pero estoy divagando) . - John M Wolfson ( charla • contribuciones ) 03:08, 21 de agosto de 2020 (UTC)
- ¿Sabemos con certeza que Bing no hará nada sobre el problema si alguien pregunta? - Tera tix ₵ 02:10, 21 de agosto de 2020 (UTC)
- Otro problema fue el potencial negativo
- Oponerse Las personas que realizan búsquedas en Google deben conocer el contexto en el que está presente la información. Como se indica en la sección de notas técnicas, las páginas de discusión de los BLP ya no están indexadas. Además, la mayoría de las páginas internas que no queremos que se indexen, como todas las discusiones de eliminación, investigaciones de derechos de autor, etc., ya no están indexadas. No hay necesidad de aplicar una manta sin indexar todo lo que se habla. Google es un motor de búsqueda mucho más sofisticado que el que tenemos internamente: si recuerdas que alguien dijo algo en una página de discusión pero no puedes recordar la redacción exacta, es más probable que la búsqueda de Google produzca el resultado correcto que la búsqueda interna. La búsqueda interna es buena solo para cadenas exactas. SD0001 ( conversación ) 03:25, 20 de agosto de 2020 (UTC)
- SD0001 , acabo de comprobar Bing para ver si la página de discusión de Donald Trump está indexada. Descubrí que solo la página de discusión de Donald Trump está desindexada; todos los archivos están indexados, lo que todavía plantea un problema con respecto a los BLP, ya que el contenido potencialmente difamatorio no debería aparecer en ningún rango de motor de búsqueda. Algo que podría solucionar la desindexación de páginas en el espacio de nombres de Talk:. A a s i m 07:24, 20 de agosto de 2020 (UTC)
- La solución sería que los bots de archivo no aplicaran indexación al crear archivos de una página de discusión no indexada. SD0001 ( conversación ) 07:52, 20 de agosto de 2020 (UTC)
- Eso funcionaría un poco si no tuviéramos más de 1000000 BLP (y muchos más archivos). Si tuviéramos menos archivos, definitivamente sería una solución práctica. Agregar __NOINDEX__ a los millones de archivos que teníamos (oa {{ talkarchive }}) desperdiciaría innecesariamente una gran cantidad de recursos del servidor, y los motores de búsqueda necesitarían tiempo para dejar de desindexar los millones de archivos. Además, como mencioné anteriormente, tenemos contenido difamatorio en páginas de discusión de no BLP y no sería práctico intentar suprimir cada uno de estos contenidos difamatorios. Desactivar la indexación de páginas de discusión hace que este contenido forme parte de la web profunda y oscura. Sé que puede ser un inconveniente para los editores que intentemos encontrar archivos, pero en realidad esto es solo menos del 1% de todos los lectores que revisan los archivos. Para los editores puede ser algo a lo que deben acostumbrarse, pero a los lectores probablemente les importe menos ya que muchos de ellos no miran las páginas de discusión de todos modos. (No aprendí sobre los distintos espacios de nombres y páginas de mantenimiento hasta que me topé con las páginas de cada uno de esos espacios de nombres). A a s i m 15:09, 27 de agosto de 2020 (UTC)
No hay millones de archivos. La inmensa mayoría de los más de un millón de artículos de BLP no tienen ningún archivo de charlas.Añadiendo __NOINDEX__ a los millones de archivos
Los motores de búsqueda tardarían el mismo tiempo en dejar de indexar, independientemente del método que utilicemos. En cuanto a los recursos del servidor, eso no es una gran preocupación para nosotros . La WMF recibe millones de dólares en donaciones y tiene suficientes recursos; es una tontería emplear una solución más pobre por nuestra parte solo por el bien de los recursos del servidor.... desperdiciaría innecesariamente una gran cantidad de recursos del servidor, y los motores de búsqueda necesitarían tiempo para dejar de desindexar los millones de archivos
¿Por qué reprimir? Simplemente quitar no causará indexación. Si el material es tan difamatorio, debe ser revocado / suprimido de todos modos, independientemente de si la página está indexada. SD0001 ( conversación ) 08:29, 29 de agosto de 2020 (UTC)Además, como mencioné anteriormente, tenemos contenido difamatorio en páginas de discusión que no son BLP y no sería práctico intentar [[WP: OVER | suprimir]] cada uno de estos contenidos difamatorios.
- Corrí algunos números: resulta que solo existen 13494 archivos de conversación de BLP . Eso es bastante trivial para noindex usando un bot. SD0001 ( conversación ) 16:04, 30 de agosto de 2020 (UTC)
- Eso funcionaría un poco si no tuviéramos más de 1000000 BLP (y muchos más archivos). Si tuviéramos menos archivos, definitivamente sería una solución práctica. Agregar __NOINDEX__ a los millones de archivos que teníamos (oa {{ talkarchive }}) desperdiciaría innecesariamente una gran cantidad de recursos del servidor, y los motores de búsqueda necesitarían tiempo para dejar de desindexar los millones de archivos. Además, como mencioné anteriormente, tenemos contenido difamatorio en páginas de discusión de no BLP y no sería práctico intentar suprimir cada uno de estos contenidos difamatorios. Desactivar la indexación de páginas de discusión hace que este contenido forme parte de la web profunda y oscura. Sé que puede ser un inconveniente para los editores que intentemos encontrar archivos, pero en realidad esto es solo menos del 1% de todos los lectores que revisan los archivos. Para los editores puede ser algo a lo que deben acostumbrarse, pero a los lectores probablemente les importe menos ya que muchos de ellos no miran las páginas de discusión de todos modos. (No aprendí sobre los distintos espacios de nombres y páginas de mantenimiento hasta que me topé con las páginas de cada uno de esos espacios de nombres). A a s i m 15:09, 27 de agosto de 2020 (UTC)
- La solución sería que los bots de archivo no aplicaran indexación al crear archivos de una página de discusión no indexada. SD0001 ( conversación ) 07:52, 20 de agosto de 2020 (UTC)
- SD0001 , acabo de comprobar Bing para ver si la página de discusión de Donald Trump está indexada. Descubrí que solo la página de discusión de Donald Trump está desindexada; todos los archivos están indexados, lo que todavía plantea un problema con respecto a los BLP, ya que el contenido potencialmente difamatorio no debería aparecer en ningún rango de motor de búsqueda. Algo que podría solucionar la desindexación de páginas en el espacio de nombres de Talk:. A a s i m 07:24, 20 de agosto de 2020 (UTC)
- Soporte por arriba. También me sorprendió que este no fuera el caso. Puedo imaginar al lector de Joe medio reaccionando con desinterés o frustración cuando el contenido de la página que espera ver no coincide con el contenido de la página que está viendo en realidad. Neto negativo en el mejor de los casos. - F ASTILAMENTE 07:45, 20 de agosto de 2020 (UTC)
- Fuerte oposición a nuestras páginas de discusión son una parte valiosa de lo que hace que Wikipedia sea única. No deberíamos estar ocultándolo. - Th e DJ ( hablar • contribuciones ) 08:00, 20 de agosto de 2020 (UTC)
- Apoyar Contra lo TheDJ dice más arriba, nuestras páginas de discusión son demasiado a menudo en el mejor embarazoso y en el tiempo al borde de la calumnioso, con doxing ya veces insultos inaceptables. Puedo señalar al menos una página de discusión que consiste solo en insultos y peroratas. Nuestro motor interno funciona. Dejar el contenido difamatorio abierto al público es en mi humilde opinión inaceptable. Doug Weller charla 08:53, 20 de Agosto 2020 (UTC)
- Fuerte oposición : no estoy de acuerdo en que las páginas de discusión no sean útiles como resultado de búsqueda, tanto para los lectores como para los editores. Benjamin ( charla ) 09:55, 20 de agosto de 2020 (UTC)
- Oponerse Cuando un lector llega a una página de discusión por accidente, verá rápidamente que no es un artículo normal de Wikipedia, ya que las publicaciones están firmadas, hay personas que se responden entre sí, etc. Creo que podemos confiar en que el lector entenderá que es una página de discusión. Si solo estaban buscando el artículo, hay un enlace en la parte superior, que creo que encontrarán rápidamente. Además, como señaló xaosflux, la plantilla "BLP" contiene
__NOINDEX__
, por lo que la difamación no es realmente una preocupación. Las discusiones de la página de conversación pueden ser bastante interesantes, por lo que creo que el valor del lector se perdería si desindexamos todo el espacio de nombres de Talk :. PJvanMill ) charla ( 11:26, 20 de agosto de 2020 (UTC) - Oppose Los motores de búsqueda ya emplean algoritmos sofisticados para ayudar a sus usuarios a encontrar lo que buscan. Nuestras páginas de discusión son públicas y abiertas a todos, en lugar de ser privadas y privilegiadas. Puede ser que sean exactamente lo que busca el buscador. Deberíamos dejar esas decisiones a los buscadores y a los proveedores en lugar de cuestionarlos y censurar preventivamente todo. Si hay un problema, es que nuestras páginas de discusión se entienden y usan muy poco. Esta propuesta empeoraría las cosas. Andrew 🐉 ( charla ) 13:50, 20 de agosto de 2020 (UTC)
- Las páginas de Support Talk pueden ser interesantes, pero no son el contenido de Wikipedia . Los artículos son el contenido, todo el resto existe para apoyar el proceso de elaboración del contenido. - GhostInTheMachine me habla a las 15:17, 20 de agosto de 2020 (UTC)
- Las páginas de Oppose Talk están lo suficientemente ocultas, pero son una parte fundamental de Wikipedia. No creo que deban ocultarse más, es mejor eliminar el contenido problemático como lo ve y luego implementar esta propuesta general. Gracias. Mike Peel ( charla ) 16:09, 20 de agosto de 2020 (UTC)
- Soporte Si bien recibo los argumentos de "nuestra búsqueda es insuficiente" (aunque no necesariamente estoy de acuerdo con ellos), pienso en la cantidad de violaciones de BLP que se llevan a las páginas de discusión para degradar los temas de los artículos y luego la idea de que aparezcan en los resultados de búsqueda? Eso hace que se me ponga la piel de gallina .-- Jorm ( charla ) 18:38, 20 de agosto de 2020 (UTC)
- Comentario - Especial: PermaLink / 862856598 # Evitar que los nuevos usuarios permitan que los motores de búsqueda indexen las páginas de los usuarios, lo que provocó que el spam en el espacio de usuario se redujera a la mitad de la noche a la mañana. No tengo conocimiento de ningún spam sistemático en el espacio de nombres de la charla. MER-C 19:08, 20 de agosto de 2020 (UTC)
- Oponerse hasta el momento en que el motor de búsqueda de MediaWiki se mejore significativamente. 207.161.86.162 ( conversación ) 22:36, 20 de agosto de 2020 (UTC)
- Las páginas de Support Talk pueden confundir a los lectores. Dependiendo de la búsqueda de un usuario, el motor de búsqueda puede abrir una página de discusión (ningún motor de búsqueda es perfecto). P, TO 19104 ( charla ) ( contribuciones ) 23:03, 20 de agosto de 2020 (UTC)
- Apoyo estratégico , con mi voto actual siendo una abstención porque no soy un experto en los resultados de los motores de búsqueda y, por lo tanto, me siento WP: UNQUALIFIED para sopesar todas las posibles ramificaciones de esto. Pero a partir de los votos! Anteriores, me preocupa que algunos editores estén priorizando su propio deseo de poder buscar páginas en Google en lugar de poner el WP: READER primero, por lo que eso me empuja a un apoyo estratégico para contrarrestarlo. Encuentro los argumentos de apoyo anteriores de que las páginas de discusión no son parte de la enciclopedia propiamente dicha ( un concepto tan mal definido como el de WP) y, por lo tanto, generalmente no deberían aparecer en los resultados de búsqueda de Google de manera persuasiva. {{u | Sdkb }} charla 02:39, 21 de agosto de 2020 (UTC)
- ¿Cómo perjudica al lector la indexación de páginas de discusión y por qué sólo deberían indexarse las páginas que forman parte de la "enciclopedia propiamente dicha"? - Tera tix ₵ 03:20, 21 de agosto de 2020 (UTC)
- Teratix , ¡mucho apoyo! Los votos aquí han argumentado por qué sería así y por qué no querríamos que aparecieran páginas internas en los resultados de Google. Amplío mis puntos de vista sobre las partes de Wikipedia orientadas al lector frente a las que no están orientadas al lector aquí; parte de lo que se reduce es que debemos poder distinguir entre el producto que trabajamos para crear (una enciclopedia) y los esfuerzos que entran en la creación de ese producto. Volviendo a WP: Reader , la opinión que tengo con más fuerza aquí es que no es apropiado votar teniendo en cuenta solo o principalmente nuestros propios deseos de poder encontrar las páginas internas que nos conciernen mucho, pero no 99 % de usuarios de Wikipedia, ya que no estamos haciendo Wikipedia solo para nosotros, sino para el mundo. Al menos algunas personas arriba claramente parecen estar centrando sus propias necesidades en lugar de las de los lectores, de ahí mi voto. {{u | Sdkb }} charla 00:24, 22 de agosto de 2020 (UTC)
- Por lo que he visto hasta ahora, los argumentos de apoyo se reducen a agitar vagamente la posibilidad de confusión del lector y la posible presentación de difamación e información engañosa. Sin embargo, no han presentado ninguna evidencia de que este sea un problema significativo, más allá de un par de casos aislados. La distinción entre "orientado al lector" y "orientado al no lector" es un punto interesante (aunque yo diría que las páginas de discusión no estarían orientadas al lector), pero simplemente invita a otra pregunta: ¿por qué deberían desindexarse las páginas que no están orientadas al lector? Finalmente, es un poco falso asumir que los opositores solo están tomando en cuenta sus propias experiencias. Quizás simplemente han descubierto que el hecho de que las páginas de discusión estén indexadas o no tiene poco impacto en las experiencias de los lectores, por lo que no han incluido esta consideración en sus comentarios. - Tera tix ₵ 02:06, 23 de agosto de 2020 (UTC)
- No creo que las preocupaciones de BLP aquí sean insignificantes o restringidas a casos aislados. De manera rutinaria, tenemos discusiones en las páginas de conversación de BLP sobre si incluir o excluir información confidencial que pueda afectar la privacidad. Somos uno de los diez mejores sitios web del mundo, por lo que cualquier cosa que publiquemos aquí, incluso en nuestras páginas de discusión, tiene el potencial de exponer el contenido a significativamente más personas que si no lo hubiéramos publicado. Take Talk: 2020 Twitter bitcoin scam # Precaución preventiva , que es una discusión que ocurrió hace solo unas semanas sobre si deberíamos nombrar a un joven de 17 años que ha sido acusado de cometer un delito cibernético notable. En la discusión en este momento, alguien ha pegado un enlace al sitio web de un oscuro tribunal del condado con instrucciones sobre cómo acceder a los registros judiciales. Sí, la información es técnicamente pública, pero hemos aumentado la exposición de la información al incluirla aquí (y sería una violación de WP: BLPPRIMARY depender de los registros judiciales como la única fuente para cualquier contenido de BLP). En otras palabras, somos demasiado indulgentes con lo que toleramos en las páginas de discusión en las discusiones de rutina para que sea una buena idea indexar las páginas de discusión. Mz7 ( charla ) 06:17, 23 de agosto de 2020 (UTC)
- Desde que se publicó el enlace el 1 de agosto, el artículo se ha visto unas 30.000 veces , pero la página de discusión solo se ha visto 181 veces . Yo diría que no todos los que vieron la página de discusión realmente hicieron clic en el enlace (es probable que bastantes espectadores solo estén allí con fines de edición); la cantidad de personas que visitaron la página de discusión, se desplazaron hasta el final, hicieron clic en el enlace, buscaron el registro y de otra manera no habrían tenido el deseo y la capacidad de encontrarlo, serían pocas o ninguna. (Y la cantidad que lo encontró porque la página de discusión se incluyó en los resultados de búsqueda sería aún menor) - Tera tix ₵ 04:54, 24 de agosto de 2020 (UTC)
- No creo que las preocupaciones de BLP aquí sean insignificantes o restringidas a casos aislados. De manera rutinaria, tenemos discusiones en las páginas de conversación de BLP sobre si incluir o excluir información confidencial que pueda afectar la privacidad. Somos uno de los diez mejores sitios web del mundo, por lo que cualquier cosa que publiquemos aquí, incluso en nuestras páginas de discusión, tiene el potencial de exponer el contenido a significativamente más personas que si no lo hubiéramos publicado. Take Talk: 2020 Twitter bitcoin scam # Precaución preventiva , que es una discusión que ocurrió hace solo unas semanas sobre si deberíamos nombrar a un joven de 17 años que ha sido acusado de cometer un delito cibernético notable. En la discusión en este momento, alguien ha pegado un enlace al sitio web de un oscuro tribunal del condado con instrucciones sobre cómo acceder a los registros judiciales. Sí, la información es técnicamente pública, pero hemos aumentado la exposición de la información al incluirla aquí (y sería una violación de WP: BLPPRIMARY depender de los registros judiciales como la única fuente para cualquier contenido de BLP). En otras palabras, somos demasiado indulgentes con lo que toleramos en las páginas de discusión en las discusiones de rutina para que sea una buena idea indexar las páginas de discusión. Mz7 ( charla ) 06:17, 23 de agosto de 2020 (UTC)
- Por lo que he visto hasta ahora, los argumentos de apoyo se reducen a agitar vagamente la posibilidad de confusión del lector y la posible presentación de difamación e información engañosa. Sin embargo, no han presentado ninguna evidencia de que este sea un problema significativo, más allá de un par de casos aislados. La distinción entre "orientado al lector" y "orientado al no lector" es un punto interesante (aunque yo diría que las páginas de discusión no estarían orientadas al lector), pero simplemente invita a otra pregunta: ¿por qué deberían desindexarse las páginas que no están orientadas al lector? Finalmente, es un poco falso asumir que los opositores solo están tomando en cuenta sus propias experiencias. Quizás simplemente han descubierto que el hecho de que las páginas de discusión estén indexadas o no tiene poco impacto en las experiencias de los lectores, por lo que no han incluido esta consideración en sus comentarios. - Tera tix ₵ 02:06, 23 de agosto de 2020 (UTC)
- Teratix , ¡mucho apoyo! Los votos aquí han argumentado por qué sería así y por qué no querríamos que aparecieran páginas internas en los resultados de Google. Amplío mis puntos de vista sobre las partes de Wikipedia orientadas al lector frente a las que no están orientadas al lector aquí; parte de lo que se reduce es que debemos poder distinguir entre el producto que trabajamos para crear (una enciclopedia) y los esfuerzos que entran en la creación de ese producto. Volviendo a WP: Reader , la opinión que tengo con más fuerza aquí es que no es apropiado votar teniendo en cuenta solo o principalmente nuestros propios deseos de poder encontrar las páginas internas que nos conciernen mucho, pero no 99 % de usuarios de Wikipedia, ya que no estamos haciendo Wikipedia solo para nosotros, sino para el mundo. Al menos algunas personas arriba claramente parecen estar centrando sus propias necesidades en lugar de las de los lectores, de ahí mi voto. {{u | Sdkb }} charla 00:24, 22 de agosto de 2020 (UTC)
- ¿Cómo perjudica al lector la indexación de páginas de discusión y por qué sólo deberían indexarse las páginas que forman parte de la "enciclopedia propiamente dicha"? - Tera tix ₵ 03:20, 21 de agosto de 2020 (UTC)
- Apoyo , y también me sorprende que este no sea el status quo. Somos un poco más indulgentes con el tipo de información que permitimos permanecer en las páginas de discusión que en el espacio principal, particularmente con respecto al contenido de WP: BLP . Por ejemplo, podríamos usar la página de discusión para discutir si cierta información límite constituye una violación de BLP (por ejemplo , nombres de víctimas , acusaciones de delitos , nombres completos y fechas de nacimiento , etc.), e incluso si el consenso es omitir el contenido de la artículo, en general el contenido permanece visible en la página de discusión, lo cual es problemático si los lectores pueden encontrarlo a través de una búsqueda en Google. La alternativa tendría que ser aplicar más liberalmente el blanqueo de cortesía a tales discusiones, lo que no se hace de forma rutinaria en la actualidad. Encuentro el argumento sobre la función de búsqueda de MediaWiki poco convincente; Ciertamente, podemos vivir sin la búsqueda de Google de archivos de páginas de discusión, especialmente con el beneficio de reducir la probabilidad de que un lector se encuentre con contenido que no está destinado a ser dirigido al lector. Mz7 ( conversación ) 05:32, 21 de agosto de 2020 (UTC)
- Soporte : las páginas de discusión son discusiones internas para el espacio de nombres del artículo destinado al público. Hay una gran cantidad de contenido inapropiado en el espacio de Talk que no necesita ser indexado en motores de búsqueda externos. Tampoco se puede esperar que todos los usuarios de los motores de búsqueda comprendan cómo funciona Wikipedia y que las páginas de Talk pueden contener tonterías generadas por el usuario que de otro modo violarían las políticas de Wikipedia en los artículos. - MarkH 21 talk 06:21, 21 de agosto de 2020 (UTC)
- Soporte : Wikipedia: Administration ... "Los espacios de nombres administrativos se utilizan para ayudar a la creación de contenido y deben considerarse mutuamente excluyentes de las páginas de contenido, excepto en los casos en que se requiere un enlace. En otras palabras, las páginas de administración deben estar en el fondo y no visible para el lector ". - Moxy 🍁 10:11, 21 de agosto de 2020 (UTC)
- Oponerse , porque las páginas de discusión son una parte muy importante de nuestros procesos y arrojan luz sobre nuestro contenido. Todos se vuelven más tontos si los ignoran. Nemo 11:08, 21 de agosto de 2020 (UTC)
- Me opongo a que no puedo hablar por otros usuarios, sin embargo, uso un motor de búsqueda (Google, en mi caso) para encontrar páginas de discusión. El motor de búsqueda es mucho más efectivo que la barra de búsqueda de Wikipedia, y tendría muchas dificultades para encontrar discusiones si no estuvieran indexadas. Sin embargo, reconozco que esta discusión es sobre WP: READER , no sobre los usuarios. En lo que respecta a eso, realmente no veo el daño de mantenerlos indexados. Cualquiera es libre de ver el trabajo entre bastidores que se incluye en cada artículo, y creo que le da a Wikipedia más credibilidad cuando la gente está expuesta a las interminables discusiones que han ayudado a construir y mantener los artículos que leen. El OP mencionó que los lectores pueden confundirse con las páginas de discusión que encuentran en los resultados de los motores de búsqueda. Esto puede ser cierto (y no estoy convencido de que lo sea), pero es irrelevante. No saber qué es la página de discusión no hace que sea más difícil leer los artículos que encuentran. Solo significa que harán clic en el enlace, verán que no es un artículo normal y se irán. No obstaculiza la experiencia de alguien que fue directamente a un artículo de los resultados del motor de búsqueda. - desconcertado vegetal ¿ Ya es la hora del té? 13:29, 21 de agosto de 2020 (UTC)
- Soporte . Estoy de acuerdo en que el motor de búsqueda interno es terrible. Pero Wikipedia está en el mundo real . A los objetivos de la difamación no les importa nuestra capacidad para encontrar discusiones antiguas en las páginas de discusión. Sí, la mayoría de las páginas de conversación de BLP no están indexadas, pero los archivos no lo están, y la difamación también puede ocurrir en páginas de conversación que no son de BLP. Suffusion of Yellow ( charla ) 20:41, 21 de agosto de 2020 (UTC)
- Apoyo Creo que mucha gente asume demasiado del lector casual. Cuando la gente busca a Paul A. Bonacci y hace clic en el enlace (como lo han hecho dos mil en los últimos 30 días) y encuentra que la primera oración es "Este es un caso real. Paul es una persona real. Este caso necesita escuché, es el primer pizzería. Si te encuentras aquí, no pares ... sigue investigando, todo está ahí "Wikipedia en sí misma está esencialmente difundiendo información errónea; nuestra reputación como fuente confiable se ve perjudicada cada vez que esto sucede, a pesar de que unos pocos lectores selectos pueden suponer con precisión el propósito de la página. Nuestro objetivo es brindar al público acceso al conocimiento del mundo, no brindar a los editores una herramienta de búsqueda marginalmente más conveniente para el espacio de nombres de la charla, y ciertamente no engañarlos activamente al vincularlos a páginas que no forman parte de la enciclopedia con contenido que es presentado en un formato algo similar a un artículo que viola todos los pilares de Wikipedia . Por el bien del lector, las páginas de discusión no deberían aparecer en Google. Zoozaz1 ( charla ) 03:39, 22 de agosto de 2020 (UTC)
- Oponerse . Andrew Davidson da en el clavo con:
Si hay un problema, es que nuestras páginas de discusión se entienden y usan muy poco.
No estoy convencido como algunos de los opositores de que un lector que se tropieza con una página de discusión entienda de inmediato lo que está mirando. Nuestros métodos de enhebrado de discusiones están ahora 20 años atrasados. Pero debería ser más fácil y más común para un lector encontrarse en páginas que no son artículos. Alguien que encuentre una página de discusión podría ser una puerta de entrada para aprender más sobre qué es Wikipedia y cómo funciona. Los lectores no deben creer que están viendo un sitio web de contenido fáctico que mágicamente aparece o ha existido desde siempre, sino una obra inacabada, imperfecta con una procedencia que se construye a lo largo del tiempo mediante la colaboración y la comunicación. Todo editor ya es un lector, pero todo lector debería ser un editor (aunque solo sea en el sentido de que sepa cómo corregir un error tipográfico o eliminar el vandalismo o las falsedades si lo ven). - Bilorv ( charla ) 20:02, 22 de agosto de 2020 (UTC)- Bilorv , estoy de acuerdo en que estamos un poco atrasados en términos de páginas de discusión y usabilidad. También estoy de acuerdo en que un lector que quiera saber cómo funciona Wikipedia puede ver las páginas de discusión. Es importante recordar que ninguna página de Wikipedia es completamente privada; tenemos algunas wikis privadas y el software MediaWiki permite ocultar páginas, pero ninguna de esas funciones está habilitada en la Wikipedia en inglés. Los lectores aún pueden ver las páginas de discusión haciendo clic en los enlaces "Charla" o "Discusión" en la parte superior de cada página. Pero incluso entonces, la mayoría de los lectores no están muy interesados en cómo funciona Wikipedia. Y si es así, pueden ver nuestras políticas, pautas, etc. y nuestros tutoriales ellos mismos y / o intentar editar ellos mismos (y obtener orientación). Sin embargo, la mayoría de los lectores que buscan temas en Google o Bing no buscan páginas de discusión. A a s i m 08:53, 23 de agosto de 2020 (UTC)
- Soporte El espacio principal en sí tiene su parte justa de sesgos difamatorios y comentarios POV, pero las páginas de conversación tienen aún menos control. Y hay millones de ellos. Los depósitos de chatarra tienen una cerca por una razón. - Pudeo ( conversación ) 23:44, 22 de agosto de 2020 (UTC)
- Soporte Recuerdo que una vez reporté una inquietud de BLP y una razón (había otras) para no eliminarla fue que estaba en la página de discusión. Dejamos que se deslicen más en este espacio que en otros. Si un editor está buscando un artículo en Google, está buscando el artículo en Google, no el proceso entre bastidores que llevó a que se hiciera ese artículo. Si bien no debemos ocultar cómo hacemos la salchicha, no necesitamos enviar a personas en busca de un carnicero a las fábricas de carne. AIR corn (charla) 02:22, 23 de agosto de 2020 (UTC)
- SOPORTE FUERTE : El lector no necesita ver cómo se hace la salchicha . Los editores activos saben cómo encontrar la información de "charla" que buscan. GenQuest "Talk to Me" 16:59, 24 de agosto de 2020 (UTC)
- Soporte ' El proceso de cómo se mejoran los artículos es interno del proyecto y, aunque es público, no debe anunciarse en los motores de búsqueda más de lo necesario. Por extraño que parezca, no recuerdo haber recibido visitas a páginas de discusión buscando en Google hasta hace poco, así que tenía la impresión de que este ya sería el predeterminado. - Matthiaspaul ( charla ) 18:45, 24 de agosto de 2020 (UTC)
- Fuerte oposición : es mejor encontrar cosas que esconderlas. EllenCT ( charla ) 01:37, 25 de agosto de 2020 (UTC)
- Oponerse Ya no tienen una clasificación muy alta y es útil para las personas que desean poder buscarlos en particular con un motor de búsqueda mejor que el nuestro. Jackmcbarn ( charla ) 05:58, 26 de agosto de 2020 (UTC)
- Mayormente ambivalente, pero a fin de cuentas opuesto por Jack. Realmente el argumento en apoyo es que las páginas de discusión no son útiles para los lectores y pueden contener contenido completamente falso (lo cual es cierto), pero de hecho, no están muy indexadas y es poco probable que el lector típico las encuentre por accidente. Sin embargo, hay una razón para mantenerlos indexados y es (para ser franco): la búsqueda de MediaWiki puede apestar. ProcrastinationReader ( charla ) 20:36, 26 de agosto de 2020 (UTC)
- Apoyaría esto si hubiera una forma alternativa confiable de encontrar consensos en las páginas de discusión, pero no la hay, así que tengo que oponerme. S Marshall T / C 13:01, 27 de agosto de 2020 (UTC)
- Soporte Si la gente quiere ver por qué ponemos algo, entonces la página de discusión no es difícil de encontrar. Sin embargo, no quiero que los recursos del servidor se desperdicien mucho en esto; No sé mucho sobre informática, pero si es posible establecer un límite en la cantidad de RAM (?) Que está usando para no ralentizar el sitio web, sería óptimo. ping me al responder, gràcies! TheKaloo talk 23:35, 27 de agosto de 2020 (UTC)
- Oponerse a los demás que han señalado que los motores de búsqueda externos suelen ser fundamentales para los editores que intentan identificar discusiones antiguas. - Paul_012 ( charla ) 09:43, 28 de agosto de 2020 (UTC)
- Me opongo , creo que nuestros lectores están bastante interesados en el proceso de redacción de los artículos. Comentarios sobre la charla: Kamala Harris apareció en las noticias hace solo dos semanas , y ese es solo uno de los muchos artículos sobre cómo Wikipedia maneja los eventos actuales que cita extensamente las discusiones de la página de charla (ver [5] [6] [7] para ver algunos ejemplos más recientes ]). xkcd ha hecho varios cómics satirizando páginas de discusión. Hacer que sea más difícil encontrar discusiones en la página de discusión y ver cómo se formó el contenido de un artículo hace que Wikipedia sea menos transparente y perjudica a nuestros lectores. Reacción de TheCatalyst31 • Creación 15:20, 29 de agosto de 2020 (UTC)
- Estoy en desacuerdo. Todavía es posible encontrar discusiones en la página de discusión haciendo clic en "Hablar". Aquellos que quieran encontrar páginas de discusión aún pueden usar la búsqueda extremadamente rudimentaria "MediaWiki", que está bastante anticuada en comparación con los motores de búsqueda modernos, pero aún utilizable. Y como se mencionó anteriormente, Talk: Kamala Harris ya está desindexada. Eso significa que las principales publicaciones de noticias como The Atlantic tuvieron que usar la búsqueda de MediaWiki de todos modos. A a s i m 19:24, 29 de agosto de 2020 (UTC)
- Las páginas de Support Talk son parte del proceso de discusión interna, que no es, creo, lo que los lectores están buscando. También son más propensos al abuso. Mientras que patrulla las páginas de discusión de reciente creación sin un artículo asociado, he visto varias páginas de discusión se utilizan para crear páginas de spam y detección de ataques a evitar, a veces después de que el artículo asociado se borraron y salado . Estas páginas, como se esperaba, todavía ocupaban un lugar destacado en los resultados de búsqueda. - t • c 22:00, 29 de agosto de 2020 (UTC)
Flori4nK
- Las páginas de Support Talk son parte del proceso de discusión interna de Wikipedia y, por lo tanto, sería mejor si se desindexaran. Faraón de los magos ( charla ) 04:03, 1 de septiembre de 2020 (UTC)
- Oponerse En conjunto, me parece malo moverse en la dirección de menos transparencia. Ejecutar un bot para agregar un NOINDEX a todas las páginas de BLP Talk y sus archivos suena bastante trivial, y eso cubriría adecuadamente las preocupaciones de privacidad / difamación, en mi opinión. Los archivos antiguos que se escapan y permanecen indexados, un incidente mencionado anteriormente, es una razón para etiquetar más a fondo, no para desindexar todo el espacio. XOR'easter ( charla ) 18:47, 1 de septiembre de 2020 (UTC)
- Se opone a la desindexación general. Apoye la desindexación de BLP como compromiso. La desindexación completa reduce la usabilidad para los editores, ya que la búsqueda en media wiki es muy pobre. pburka ( charla ) 20:04, 1 de septiembre de 2020 (UTC)
- El soporte como contenido en las páginas de discusión podría incluir información falsa, violaciones de derechos de autor y todo tipo de contenido que sea parte de la elaboración de una enciclopedia abierta, pero no el contenido examinado en sí. La gente ciertamente puede encontrar esta información a través de la interfaz de WP, pero no es necesario que la promocionemos externamente. - Charla de Zim Zala Bim 00:27, 3 de septiembre de 2020 (UTC)
- Soporte , el contenido de las páginas de discusión no se puede utilizar para los visitantes del motor de búsqueda, como se describe anteriormente. Deberíamos intentar mantener a las personas alejadas de las páginas de discusión por una cuestión de privacidad. Swordman97 habla conmigo 05:35, 3 de septiembre de 2020 (UTC)
- Como nota al margen, la desindexación de las páginas de discusión no conducirá a una "menor transparencia". Las páginas de discusión son una de las primeras cosas que aprendes cuando te conviertes en editor, por lo que no es tan difícil encontrarlas. Swordman97 habla conmigo 05:40, 3 de septiembre de 2020 (UTC)
- Soporte . Los usuarios que estén interesados en la discusión encontrarán las páginas de discusión. El contenido de las páginas de discusión es para consumo interno y no es necesario que aparezca en los resultados de búsqueda. Y el comentario del OP sobre el tipo de contenido dañino que podría aparecer en las páginas de discusión es significativo. Si el problema es que el motor de búsqueda interno es una porquería, entonces deberíamos mejorar el motor de búsqueda interno. Charla de Kahastok 20:40, 3 de septiembre de 2020 (UTC)
- Oponerse a la función de búsqueda de Wikipedia es bastante terrible para las búsquedas "confusas" y hace que buscar cualquier cosa que no sean artículos es onerosa y poco intuitiva. A menudo he tenido que usar Google para encontrar una discusión en la página de discusión que no pude encontrar con las herramientas de búsqueda de Wikipedia. - Ahecht (
PÁGINA DE HABLAR) 14:17, 4 de septiembre de 2020 (UTC)
Marcar ediciones para revisión
Discutido un poco en Wikipedia: Bomba de pueblo (laboratorio de ideas) # ¿Editar la bandera para revisión? donde me animaron a traer mi idea aquí para ver si podría haber consenso en la comunidad. Mi idea es que establezcamos, de manera similar a la funcionalidad de agradecimiento , la capacidad de marcar las ediciones para que las revisen otros editores. Esto podría ser útil en los casos en que un editor ve una edición problemática pero no tiene el tiempo para abordar el problema correctamente, o cuando un editor ve una edición que cree que es potencialmente problemática, pero no tiene la experiencia o la confianza. saber con certeza y no querer meter el pie en ello con una reversión inapropiada. Las ediciones marcadas podrían resaltarse en listas de seguimiento y tal vez capturarse para su revisión de otras maneras también. También podría haber un mecanismo mediante el cual los editores pudieran desmarcar las ediciones que creían que eran cómodamente sin problemas.
Más allá de etiquetar las ediciones de otros editores para su revisión, esta funcionalidad podría permitirles más fácilmente a los editores pedir a otros que revisen su trabajo. No estoy seguro de cuánto podría usarse esto realmente en tal capacidad, pero no parece una mala idea. Como ejemplo, a veces he intentado editar tablas pero no he podido conseguir que se vean como quería. Marcar mi edición sería una forma rápida de llamar la atención de otros editores.
Se sugirió en la discusión vinculada que esto podría lograrse técnicamente sin dificultad significativa así: "extender las etiquetas de cambio a más usuarios (¿administradores + rollbackers?) Y crear una nueva etiqueta llamada" marcado para revisión "(?)".
Hay algunos posibles problemas obvios aquí, que también se discutieron en el laboratorio de ideas: por ejemplo, podría ser bastante fácil acosar a otro editor marcando sus ediciones, y habilitar esta funcionalidad podría hacer que los editores sean menos propensos a "presionar el botón" ellos mismos. Sin embargo, al final, no estoy seguro de que haya una buena manera de establecer si esta mejora se abusaría lo suficiente como para ser una preocupación sin hacerla disponible y ver cómo funciona.
Doy la bienvenida a las opiniones de otros editores sobre esto; ¡gracias por tu tiempo! DonIago ( charla ) 14:31, 25 de agosto de 2020 (UTC)
- @ Doniago : No me gusta la idea de agregar una etiqueta o una plantilla con la esperanza de que otro voluntario se haga cargo del trabajo. Creo que sería mejor revertir la edición potencialmente problemática y luego comenzar una discusión en la página de discusión del artículo, siguiendo WP: BRD . O no revertirlo y publicarlo en la página de discusión. Si no tiene tiempo para hacer ni siquiera eso, vuelva a él más tarde cuando pueda ser WP: BOLD y arregle lo que pueda estar mal. También hay una patrulla de cambios recientes de WP: RCP que está atento a las cosas problemáticas. RudolfRed ( charla ) 16:45, 25 de agosto de 2020 (UTC)
- Doniago , ya tenemos una función así. Se llama cambios pendientes. Cuando está habilitado, todas las ediciones deben aprobarse antes de que sean visibles para los lectores.
- He editado wikiHow, una wiki separada, y ellos hacen precisamente eso. Pero la razón por la que pueden hacerlo es porque su comunidad es lo suficientemente pequeña como para revertir a los vándalos. Pero en Wikipedia, tenemos de 10 a 40 ediciones por segundo. Si todas esas ediciones tuvieran que revisarse de antemano, crearía una carga innecesaria para los editores.
- Tenemos bots contra el vandalismo que revierten las ediciones potencialmente problemáticas y tenemos ORES que muestra las ediciones que probablemente necesiten revisión, pero no obligamos a que todas las ediciones sean controladas. Eso crearía una enorme carga para los editores que gestionan los retrasos. En teoría, podríamos hacer eso, pero en la práctica, no lo hacemos. A a s i m 18:25, 25 de agosto de 2020 (UTC)
- Creo que me has malentendido; mi propuesta es para una función manual que permitiría a los editores humanos etiquetar las ediciones como potencialmente problemáticas. No propongo ningún tipo de proceso de backend para etiquetar automáticamente las ediciones como necesitadas de revisión. DonIago ( charla ) 18:51, 25 de agosto de 2020 (UTC)
- Creo que están diciendo cuál es el punto de eso si puedes deshacer las ediciones. Emir de Wikipedia ( charla ) 21:20, 25 de agosto de 2020 (UTC)
- Y su respuesta es que hay ediciones poco claras en las que alguien no se siente seguro de deshacer (incluso deshacer e iniciar una discusión) pero piensa que alguien más podría estar en mejores condiciones para hacer una discusión. Personalmente, no estoy seguro de si los aspectos positivos superan a los negativos de reducir el número de acciones claras. Nosebagbear ( charla ) 21:23, 25 de agosto de 2020 (UTC)
- Creo que están diciendo cuál es el punto de eso si puedes deshacer las ediciones. Emir de Wikipedia ( charla ) 21:20, 25 de agosto de 2020 (UTC)
- La Wikipedia alemana también ha habilitado algo como "Cambios pendientes" / "Revisiones marcadas". Se diferencia en los detalles de nuestra configuración. De cualquier manera, la propuesta aquí es más o menos al revés, los cambios se publican de forma predeterminada, pero podrían marcarse para su revisión (sin anular la publicación hasta que se reviertan) si alguien los encuentra cuestionables. Entonces, está en un término medio entre los extremos. Me gusta eso. - Matthiaspaul ( charla ) 18:39, 28 de agosto de 2020 (UTC)
- Creo que me has malentendido; mi propuesta es para una función manual que permitiría a los editores humanos etiquetar las ediciones como potencialmente problemáticas. No propongo ningún tipo de proceso de backend para etiquetar automáticamente las ediciones como necesitadas de revisión. DonIago ( charla ) 18:51, 25 de agosto de 2020 (UTC)
- Me gustaría ver algo en este sentido. Como gnomo, mi lista de vigilancia marca muchos cambios en temas de los que sé poco. Hoy, por ejemplo, una PI cambió el origen étnico de varios bailes, lo cual es sospechoso pero no obviamente incorrecto. Dejé un mensaje en un Wikiproject con la esperanza de que alguien con una pista lo verificara, pero el proceso podría ser más sencillo si hubiera algún tipo de bandera que pudiera ondear. Certes ( charla ) 22:08, 25 de agosto de 2020 (UTC)
- Certes , si mal no recuerdo, los administradores tienen la capacidad de editar etiquetas para una diferencia en particular. Eso significa que si hay dos ediciones incorrectas, pueden marcarlo como vandalismo. Los bots pueden hacer lo mismo. Pero sería bueno si esto se pudiera expandir a los rollbackers para que podamos aplicar las etiquetas apropiadas a una edición. A a s i m 22:34, 25 de agosto de 2020 (UTC)
- La bandera puede ser más útil para los que no son administradores; algo que un editor común puede usar para decir "por favor, ¿puede un experto echarle un vistazo a esto?". Si es solo para administradores, aún podría ser útil, pero posiblemente no valga la pena tomarse la molestia de implementarlo para una audiencia pequeña que ya tiene otros métodos disponibles. Certes ( charla ) 23:31, 25 de agosto de 2020 (UTC)
- Certes , si mal no recuerdo, los administradores tienen la capacidad de editar etiquetas para una diferencia en particular. Eso significa que si hay dos ediciones incorrectas, pueden marcarlo como vandalismo. Los bots pueden hacer lo mismo. Pero sería bueno si esto se pudiera expandir a los rollbackers para que podamos aplicar las etiquetas apropiadas a una edición. A a s i m 22:34, 25 de agosto de 2020 (UTC)
- Soy escéptico con esta idea porque no está claro cuáles serían los límites de dicha función. Sin pautas más claras sobre cuándo sería apropiado asignar a una edición una etiqueta vaga de "necesita revisión", me temo que conduciría a una situación similar a la que vimos con {{ cleanup }}, que es una etiqueta de mantenimiento de artículo que dice simplemente " Este artículo puede requerir una limpieza para cumplir con los estándares de calidad de Wikipedia ". Durante muchos años, algunos editores colocaron esta etiqueta extremadamente vaga sin proporcionar ningún detalle sobre cómo los artículos necesitaban una limpieza. Esto era claramente indeseable, y en 2012 una solicitud de comentarios finalmente hizo
|reason=
obligatorio el parámetro de la etiqueta. De manera similar, esta propuesta no parece diferente de la creación de una versión en línea de {{ cleanup }}, lo cual no es deseable si hay una etiqueta más específica que informaría mejor por qué el contenido necesita atención, p. Ej., {{ Cita requerida }}, {{ dudoso }} o {{ declaración POV }}. Consulte también Plantilla: etiquetas de limpieza en línea para obtener más de estas alternativas. Mz7 ( conversación ) 01:25, 26 de agosto de 2020 (UTC)
- Estoy de acuerdo en que implementar la plantilla de limpieza sin requerir aclaración fue un paso en falso. Dicho esto, no creo que las razones por las que uno quiera usar esta etiqueta puedan encasillarse fácilmente en plantillas existentes o posiblemente nuevas; si pudieran, abogaría por la creación de una nueva plantilla ahora mismo. :)
- Como ejemplo arbitrario, estoy revisando mi lista de seguimiento y veo un artículo de película en la lista. La diferencia muestra que un editor ha reestructurado un texto existente que aborda la recepción de la película y ha agregado información sobre lo genial (¡o terrible!) Que varios directores de cine reconocidos consideraron la película. ¿Es esta información apropiada para agregar al artículo? Sí, porque son directores de cine muy conocidos y sus opiniones importan. No, porque no se les conoce por ser críticos de cine y sus opiniones no merecen más peso que las demás. Tal vez, porque son varios directores de cine los que opinan sobre una película clásica. Me gustaría profundizar en esto, pero surge una de esas circunstancias de la vida que requiere que me aleje por una duración desconocida. No tengo tiempo para comenzar una discusión convincente en la página de Talk, y realmente no hay una plantilla adecuada que me viene a la mente de inmediato. Si puedo marcar la edición, incluso si nadie más llega a ella en el corto plazo, seguirá siendo sobresaliente, y tal vez yo mismo la vea.
- ¡Espero que esto sea útil! Estoy de acuerdo con otros editores en que no estoy realmente seguro de cuán genial es esta idea o si los posibles inconvenientes superan a los profesionales, pero al menos parecía merecer una audiencia. ¡Salud! DonIago ( charla ) 17:24, 26 de agosto de 2020 (UTC)
- Creo que Huggle tiene una funcionalidad similar, pero eso solo parecería un vandalismo flagrante (que es básicamente el propósito de Huggle). En lo que respecta a esta funcionalidad, requeriría un esfuerzo de desarrollo y, como todos saben: solo obtendrá el tiempo de desarrollo para implementar una función no trivial si encabeza la lista de deseos de la comunidad durante 3-4 años seguidos, luego espere otros 3-5 años para la asignación de recursos. Incluso entonces es un tal vez. De manera tan realista, probablemente no suceda. Lo más cerca que pudimos llegar a esto es un script de usuario que proporciona un botón para enviar una edición a un repositorio central (como WP: CCI ), o simplemente una forma más fácil de enviar una edición a una determinada página de discusión de Wikipedian para que la vean. Pero me imagino que la funcionalidad se verá abrumada rápidamente, para ser honesto. ProcrastinationReader ( charla ) 20:41, 26 de agosto de 2020 (UTC)
- @ ProcrastinationReader : Esto no requiere tiempo de desarrollo ya que la infraestructura ya existe . Los únicos cambios necesarios es la extensión del derecho de las etiquetas de cambio a los grupos de usuarios que no sean administradores (lo cual es trivial) y la creación de una nueva etiqueta (que puede hacer localmente un administrador). Lo único que realmente se requiere aquí es el consenso de la comunidad. - SD0001 ( conversación ) 10:18, 31 de agosto de 2020 (UTC)
- SD0001 , si lo entiendo correctamente, ¿otorgar derechos a esas etiquetas de cambio también permite que las personas eliminen las etiquetas? ejemplo de URL y ver derechos :
Agregue y elimine etiquetas arbitrarias en revisiones individuales y entradas de registro (etiquetas de cambio)
. No creo que sea posible desagregar esa funcionalidad y, obviamente, no queremos permitir que las personas puedan eliminar etiquetas. Si bien podríamos eludirlo (por ejemplo, un bot que revierte cualquier eliminación de etiquetas que no son esta etiqueta, o los patrulleros que ven el registro en busca de cambios de etiquetas), todavía me es indiferente. Una mejor manera puede ser "etiquetar" las revisiones usando un script (¿agregar a Twinkle, tal vez?) Que agrega una plantilla oculta a un artículo con revisiones como parámetros. Un bot compila una lista de tales revisiones (es decir, transclusiones de la plantilla con revisiones específicas). ProcrastinationReader ( charla ) 11:27, 31 de agosto de 2020 (UTC)- Meh, si alguien tiene derecho a agregar etiquetas, es natural que también les permita eliminarlas. No veo qué tiene de controvertido eso. Las revisiones de "etiquetado" mediante un script crean una nueva entrada en el historial de la página, además de que la etiqueta también debería eliminarse, lo que satura el historial. OTOH al usar la función de etiquetado nativo, solo estamos saturando el registro de etiquetas que nadie está mirando. - SD0001 ( conversación ) 11:48, 31 de agosto de 2020 (UTC)
- SD0001 , lo que quiero decir es: el problema es que podrían eliminar las etiquetas existentes (como el editor utilizado, el dispositivo móvil, etc.). Eliminar las etiquetas que han agregado está bien, pero no las otras etiquetas. ProcrastinationReader ( charla ) 12:16, 31 de agosto de 2020 (UTC)
- Meh, si alguien tiene derecho a agregar etiquetas, es natural que también les permita eliminarlas. No veo qué tiene de controvertido eso. Las revisiones de "etiquetado" mediante un script crean una nueva entrada en el historial de la página, además de que la etiqueta también debería eliminarse, lo que satura el historial. OTOH al usar la función de etiquetado nativo, solo estamos saturando el registro de etiquetas que nadie está mirando. - SD0001 ( conversación ) 11:48, 31 de agosto de 2020 (UTC)
- SD0001 , si lo entiendo correctamente, ¿otorgar derechos a esas etiquetas de cambio también permite que las personas eliminen las etiquetas? ejemplo de URL y ver derechos :
- @ ProcrastinationReader : Esto no requiere tiempo de desarrollo ya que la infraestructura ya existe . Los únicos cambios necesarios es la extensión del derecho de las etiquetas de cambio a los grupos de usuarios que no sean administradores (lo cual es trivial) y la creación de una nueva etiqueta (que puede hacer localmente un administrador). Lo único que realmente se requiere aquí es el consenso de la comunidad. - SD0001 ( conversación ) 10:18, 31 de agosto de 2020 (UTC)
- Me gusta esta propuesta, en particular si el señalador podría especificar un motivo de una lista predefinida de posibles motivos, o incluso dejar un comentario visible, de modo que sea más fácil para otros editores saber lo que deberían estar buscando. .
- Existe cierto potencial de abuso, por lo que deberíamos permitir esto solo para los usuarios que hayan iniciado sesión más allá de cierto umbral, pero el umbral debería ser razonablemente bajo para que muchos usuarios puedan usarlo. También podría ser útil seleccionar si la etiqueta de revisión debe ser visible públicamente o solo para uso personal, incluida en una lista interna especial para una revisión posterior (cuando el tiempo lo permita).
- La alternativa actual es mejorar una edición (ideal, pero a menudo no es posible debido a la falta de tiempo), revertirla o abrir un hilo de página de discusión, pero las dos últimas opciones a menudo crean estrés y drama innecesarios para problemas que podrían resolverse en formas mucho más sutiles, relajadas y amistosas si se les da suficiente tiempo y mano de obra para ver una edición.
- - Matthiaspaul ( charla ) 18:39, 28 de agosto de 2020 (UTC)
- Me imagino que agregar una lista predefinida lo haría más complejo técnicamente, pero no estoy seguro de si sería significativamente más complejo. No estoy seguro de un comentario visible, ya que en ese momento podrías hacer una edición ficticia . Acordó limitarlo a los usuarios registrados. Dado que es más probable que los editores más nuevos confíen en esta funcionalidad si estuviera disponible, estoy de acuerdo en que un umbral bajo también sería bueno.
- Mi sensación es que una etiqueta de revisión debe ser públicamente visible para que otros editores también puedan revisar y posiblemente abordar el problema ... o si creen que no hay problema, desmarque la edición.
- ¡Gracias por tus pensamientos! DonIago ( charla ) 19:18, 28 de agosto de 2020 (UTC)
- La posibilidad de especificar un motivo también existe, consulte Especial: registro / etiqueta . - SD0001 ( conversación ) 10:22, 31 de agosto de 2020 (UTC)
- Me preocupa que esto pueda convertirse en un "estatuto de troll". Seguir a un usuario marcando todo lo que está haciendo, o marcando una edición porque no está de acuerdo con una postura política o de otro tipo, o tal vez un MP o similar podría marcar una edición, lo cual es una verdad que les molesta. ¿Qué salvaguardias existen para evitar que el etiquetado de edición se vuelva manipulador? doktorb palabras hechos 10:02, 2 de septiembre de 2020 (UTC)
- ¿Además del hecho de que eso sería acoso y un delito bloqueable? DonIago ( charla ) 13:51, 2 de septiembre de 2020 (UTC)
Visualización de temas de clase A
Hola a todos, mi nombre es Rebestalic
En resumen: ¿Deberíamos mostrar temas de clase A para artículos de clase A?
La visualización de estos tópicos es inconsistente: antes de entrar en una discusión interesante con J Milburn , Nina Simone y la batalla de Pusan Perimeter lo tenían junto a sus tópicos del buen artículo, mientras que los de clase A sin el tema incluían el de Atomic. bombardeos de Hiroshima y Nagasaki .
J Milburn, que es una escoba (REBESTALIC IS A TOADY ALERT), mencionó que "no estaba al tanto de ninguna política o directriz que recomendara su inclusión". ¿Quizás ahora sea el momento de hacer tal política?
🤔 Rebestalic [deje un mensaje ...] 00:43, 27 de agosto de 2020 (UTC)
J Milburn, que es una escoba (REBESTALIC IS A TOADY ALERT)
¿Qué? ST47 ( charla ) 05:02, 27 de agosto de 2020 (UTC)- Creo que esto es un poco de humor ligero al referirse al estado de administrador de J. Milburn. - Tera tix ₵ 05:45, 27 de agosto de 2020 (UTC)
- Como un breve resumen, encontré un artículo de clase A con un "topicon" por casualidad y lo eliminé. Más tarde lo comprobé y encontré que unos 15 artículos tenían tópicos de clase A y los eliminé todos. Estos artículos eran en su mayoría de historia militar, pero había algunos más, incluido uno que decididamente no era de clase A. Los artículos destacados, las listas destacadas y los GA suelen tener temas. En la parte superior de mi cabeza, cuando introdujimos los temas para los GA, estaba en mi memoria, pero no tan recientemente, hubo una discusión centralizada al respecto. No tengo una opinión muy fuerte sobre si los artículos de la clase A deberían tener tópicos (me inclino en contra, simplemente porque la clase A no está tan centralizada o codificada como FA o GA, al menos hasta donde puedo ver) pero no lo hago ' No creo que solo algunos editores que deseen verlos los agreguen. Si va a suceder, debe haber una discusión central al respecto. Si esta es la discusión central, que así sea. Josh Milburn ( charla ) 07:26, 27 de agosto de 2020 (UTC)
- @ ST47 : Mis disculpas por no ser tan claro como pude, Teratix tiene razón con mi horrible sentido del humor Rebestalic [dejar un mensaje ...] 21:22, 27 de agosto de 2020 (UTC)
- Como un breve resumen, encontré un artículo de clase A con un "topicon" por casualidad y lo eliminé. Más tarde lo comprobé y encontré que unos 15 artículos tenían tópicos de clase A y los eliminé todos. Estos artículos eran en su mayoría de historia militar, pero había algunos más, incluido uno que decididamente no era de clase A. Los artículos destacados, las listas destacadas y los GA suelen tener temas. En la parte superior de mi cabeza, cuando introdujimos los temas para los GA, estaba en mi memoria, pero no tan recientemente, hubo una discusión centralizada al respecto. No tengo una opinión muy fuerte sobre si los artículos de la clase A deberían tener tópicos (me inclino en contra, simplemente porque la clase A no está tan centralizada o codificada como FA o GA, al menos hasta donde puedo ver) pero no lo hago ' No creo que solo algunos editores que deseen verlos los agreguen. Si va a suceder, debe haber una discusión central al respecto. Si esta es la discusión central, que así sea. Josh Milburn ( charla ) 07:26, 27 de agosto de 2020 (UTC)
- Creo que esto es un poco de humor ligero al referirse al estado de administrador de J. Milburn. - Tera tix ₵ 05:45, 27 de agosto de 2020 (UTC)
- Lean support aunque tengo mis dudas sobre la descentralización. - John M Wolfson ( charla • contribuciones ) 23:58, 27 de agosto de 2020 (UTC)
- Comentario: Aparte de MILHIST, ¿qué otros proyectos realizan activamente revisiones de clase A? ¿Son comparables las cualidades de sus artículos de clase A? Deberían serlo si un tema se va a mostrar de forma coherente para todos estos proyectos. De lo contrario, la aprobación podría realizarse proyecto por proyecto. - Paul_012 ( charla ) 09:38, 28 de agosto de 2020 (UTC)
- Hola Paul 012 , ¡de hecho hice una pregunta sobre esto justo después de unirme a Wikipedia! Fue en Teahouse, y el contestador me dirigió a la categoría de artículos de clase A (tenía que ser un enlace externo ya que no sé cómo hacer enlaces a páginas de categorías). Lo eché un vistazo hace un momento, y en su mayoría eran categorías vacías. No tengo la menor idea de en qué categoría encaja Nina Simone, porque supongo que no tuvo mucho que ver con la historia militar.
- Sin embargo, considere la sección de calificaciones de la página de evaluación de contenido ; en la columna con los códigos de clase, los campos Artículo destacado, Lista destacada, Buen artículo y Clase A tienen sus temas al lado, mientras que todas las clases de menor calidad (como las clases B y C) no lo tienen. Me pregunto por qué tampoco existe una 'Lista Buena'. ¡Pero gracias por dar tu opinión a mi hilo! Muy emocionante para mí Rebestalic [dejar un mensaje ...] 11:10, 28 de agosto de 2020 (UTC)
- Apóyate en contra: prefiero tener solo el más / estrella, basado en una revisión adecuada, centralizada y por pares. Para que la clase A funcione, tendríamos que revisar cada proyecto que quisiéramos ofrecerles y decidir que el proyecto tenía un sistema lo suficientemente bueno para manejar esa revisión, probablemente con un proceso de exclusión de la lista externo a ese proyecto. Nosebagbear ( charla ) 14:23, 30 de agosto de 2020 (UTC)
- Comentario : Necesitamos averiguar, en un nivel fundamental, qué es lo que esperamos lograr al tener una clase A como designación antes de poder responder a esta pregunta. No estoy seguro de que podamos ponernos de acuerdo sobre si la clase A es más alta o más baja que GA, y mucho menos esperar que los lectores que se encuentren con el tema puedan distinguirlo. ¿Se ha hablado (aparte de mi breve pregunta aquí ) sobre desaprobar la clase A y hacer que la revisión de los artículos de historia militar sea una especie de subtratamiento dentro de GA?
- Dicho esto, en términos generales, apoyo ( como lo he hecho en el pasado ) hacer que las calificaciones de los artículos estén más disponibles para los lectores. Es importante para mantener la confianza que dejemos en claro en qué partes de la enciclopedia generalmente pueden confiar y cuáles aún están en construcción. El obstáculo es asegurarse de que las calificaciones sean lo suficientemente precisas, y hay problemas particularmente con las calificaciones en el medio del espectro. . {{u | Sdkb }} charla 20:51, 3 de septiembre de 2020 (UTC)
- Lean oponerse. Si bien recibir una evaluación de clase A es una buena indicación de la calidad del artículo, no es el producto de ningún proceso de revisión por pares uniforme o estandarizado. Tiene un lugar (la página de discusión del artículo), pero es diferente de GA o FA en el sentido de que (como todas las evaluaciones de Wikiproject) está completamente localizado. No debe elevarse al mismo lugar que una designación para toda la comunidad. - Charla Ex Parte 16:19, 5 de septiembre de 2020 (UTC)
Mover temas protegidos
¿Realmente los necesitamos? Siempre he pensado que son un ícono bastante inútil, y solo agrega hinchazón. Casi nadie está tratando de mover estos artículos, el ícono es un desorden y debe eliminarse en mi opinión. Ejemplo salvaje, Frank Sinatra . Si es la categorización que necesitamos, podemos mantener la plantilla / bot como ahora, y simplemente editar {{ pp-move }} para eliminar el tema en la parte. ProcrastinationReader ( charla ) 17:52, 27 de agosto de 2020 (UTC)
- De acuerdo . {{u | Sdkb }} charla 08:51, 31 de agosto de 2020 (UTC)
- Quitar . El menú no ofrece la opción de mover (si no tiene permiso para mover el artículo) , lo cual tiene que ser una pista suficiente si alguien intenta moverlo. Existe una pequeña lógica para tener el estado de protección (tal vez con el motivo indicado) como uno de los elementos al comienzo de la página de discusión. - GhostInTheMachine habla conmigo 09:22, 31 de agosto de 2020 (UTC)
- El menú mover ofrece la opción de mover la página. Una página se puede mover protegida en, por ejemplo, el nivel confirmado extendido, dejando la opción de moverla disponible para usted, pero no para los editores más nuevos. ~ Amory ( u • t • c ) 10:13, 31 de agosto de 2020 (UTC)
- Creo que a eso se refería Ghost. Ese solo puede ver el botón de movimiento si tiene permiso para moverlo. ProcrastinationReader ( charla ) 12:47, 31 de agosto de 2020 (UTC)
- De hecho, por lo tanto: el botón de movimiento es un indicador confiable de si puede o no mover una página, pero no es un indicador confiable de si una página está protegida contra movimiento, que es lo que indica el icono. Similar para "ver código fuente" vs "editar" para protección contra edición. ~ Amory ( u • t • c ) 18:30, 31 de agosto de 2020 (UTC)
- Ah, te sigo ahora. ¿Sin embargo, ese caso específico importa? Es decir, casi todos los editores (y sin duda el 99,9% de los lectores) realmente no importa si una página es mover protegida, independientemente de si se pueden mover. Tal vez un editor aquí o allá lo hace (y pueden hacer clic en "información de la página"), y dichos editores normalmente serían editores habituales de la página, pero en mi opinión, no justifica mostrar ese icono inútil a todos los editores y no registrados. en lector. Si debería mostrarse, creo que debería ser opt-in (por medio de un gadget, más o menos), en lugar de ser predeterminado para todos. ProcrastinationReader ( charla ) 19:37, 31 de agosto de 2020 (UTC)
- No he expresado una opinión, solo señalo que los dos no son intercambiables ya que no transmiten la misma información; si importa, depende de usted. Los lectores nunca pueden mover una página (suponiendo que los lectores no hayan iniciado sesión), por lo que el icono es en realidad la única forma de transmitir la información. Una vez más, hago una analogía con "ver fuente" para proteger la edición. ~ Amory ( u • t • c ) 00:12, 1 de septiembre de 2020 (UTC)
por lo que el icono es en realidad la única forma de transmitir la información
acerca de hacer clic en "Información de la página", por ejemplo, [8] ProcrastinationsReader ( charla ) 11:00, 1 de septiembre de 2020 (UTC)
- No he expresado una opinión, solo señalo que los dos no son intercambiables ya que no transmiten la misma información; si importa, depende de usted. Los lectores nunca pueden mover una página (suponiendo que los lectores no hayan iniciado sesión), por lo que el icono es en realidad la única forma de transmitir la información. Una vez más, hago una analogía con "ver fuente" para proteger la edición. ~ Amory ( u • t • c ) 00:12, 1 de septiembre de 2020 (UTC)
- Ah, te sigo ahora. ¿Sin embargo, ese caso específico importa? Es decir, casi todos los editores (y sin duda el 99,9% de los lectores) realmente no importa si una página es mover protegida, independientemente de si se pueden mover. Tal vez un editor aquí o allá lo hace (y pueden hacer clic en "información de la página"), y dichos editores normalmente serían editores habituales de la página, pero en mi opinión, no justifica mostrar ese icono inútil a todos los editores y no registrados. en lector. Si debería mostrarse, creo que debería ser opt-in (por medio de un gadget, más o menos), en lugar de ser predeterminado para todos. ProcrastinationReader ( charla ) 19:37, 31 de agosto de 2020 (UTC)
- De hecho, por lo tanto: el botón de movimiento es un indicador confiable de si puede o no mover una página, pero no es un indicador confiable de si una página está protegida contra movimiento, que es lo que indica el icono. Similar para "ver código fuente" vs "editar" para protección contra edición. ~ Amory ( u • t • c ) 18:30, 31 de agosto de 2020 (UTC)
- Creo que a eso se refería Ghost. Ese solo puede ver el botón de movimiento si tiene permiso para moverlo. ProcrastinationReader ( charla ) 12:47, 31 de agosto de 2020 (UTC)
- El menú mover ofrece la opción de mover la página. Una página se puede mover protegida en, por ejemplo, el nivel confirmado extendido, dejando la opción de moverla disponible para usted, pero no para los editores más nuevos. ~ Amory ( u • t • c ) 10:13, 31 de agosto de 2020 (UTC)
Limpieza después de las ediciones de #WPWP
Como resultado de la campaña Páginas de Wikipedia que quieren fotos que se ejecuta en Meta desde julio y que finaliza este 31 de agosto, ha habido muchas ediciones de mala calidad por parte de editores que no están familiarizados con la política de uso de imágenes / MOS y / o simplemente no lo hacen. preocuparse por la calidad. Algunos tenían una ubicación incorrecta de la imagen, algunos introdujeron títulos incorrectos, algunos insertaron imágenes totalmente irrelevantes y algunos cuadros de información y otras plantillas completamente rotas. Dado que muchos de los artículos afectados son de temas oscuros que no se han visto, es posible que se necesite un esfuerzo de limpieza coordinado. ¿Quizás un tablón de anuncios centralizado para identificar a los editores problemáticos y verificar sus contribuciones? Hubo una discusión anterior en AN, pero no pareció llegar a ninguna conclusión. - Paul_012 ( charla ) 09:27, 28 de agosto de 2020 (UTC)
- Me gustaría señalar que tenemos el Filtro 1073 para registrarlos, por lo que no es difícil de rastrear, pero hay 32k visitas. ProcrastinationReader ( charla ) 14:13, 28 de agosto de 2020 (UTC)
- Gracias, ProcrastinationReader . Me perdí que el filtro de edición ya se había implementado. ¿Sabría si hay una manera de obtener una lista desduplicada de usuarios que han activado el filtro, de modo que se puedan realizar comprobaciones al azar? - Paul_012 ( charla ) 17:02, 28 de agosto de 2020 (UTC)
- Ese filtro de edición debería cambiarse y configurarse para no permitir la edición y, a partir de este punto en adelante, este evento debería prohibirse por todos los medios en este proyecto. Es perturbador y, para ser muy franco, es un dolor de cabeza para nosotros que tenemos que hacerlo. revise las contribuciones de todos y revise todas y cada una de las ediciones. - Charla de Davey 2010 20:51, 30 de agosto de 2020 (UTC)
- Gracias, ProcrastinationReader . Me perdí que el filtro de edición ya se había implementado. ¿Sabría si hay una manera de obtener una lista desduplicada de usuarios que han activado el filtro, de modo que se puedan realizar comprobaciones al azar? - Paul_012 ( charla ) 17:02, 28 de agosto de 2020 (UTC)
- Es genial que tengamos nuevos editores como parte de esto, incluso si todavía no están haciendo las cosas bien. Espero que les dé la bienvenida y les enseñe cómo editar mejor Wikipedia. Gracias. Mike Peel ( charla ) 19:35, 3 de septiembre de 2020 (UTC)
Borrar avisos de edición caducados
Notificación de una discusión en la charla de Wikipedia: Editnotice propone la limpieza de mantenimiento de los editnotices caducados al dejar en blanco, aquí . ProcrastinationReader ( charla ) 14:08, 28 de agosto de 2020 (UTC)
Agregue la clasificación ESRB / CERO / PEGI a las listas de videojuegos.
Como sugiere el nombre, sería muy beneficioso agregar la calificación del juego al panel de información del lado derecho.
Esto también podría tener la ventaja adicional de vincular de nuevo a la página de calificaciones (porque CERO A, B, C, etc. para mí es muy confuso a menos que mires sus significados / rango de edad).
Como hay muchos sistemas en todo el mundo, tal vez una configuración regional basada en la traducción del sitio (como el Reino Unido solo ve PEGI, Alemania solo ve USK, etc.) y que el artículo .com contenga las principales áreas de publicación (generalmente Japón, América del Norte y Europa). - 2600: 1702: 260: 9100: C184: A0D6: 6368: 8E56 ( conversación ) 05:27, 29 de agosto de 2020 (UTC)
- Solían incluirse, pero se eliminaron por consenso hace años. Charla de plantilla: Videojuego de Infobox / Archivo 11 # Proponer la eliminación de la sección de calificaciones. . Cualquier propuesta para agregarlos nuevamente necesitaría explicar qué cambió desde esa discusión y WP: VG debe ser informado de esta discusión .-- 67.68.208.64 ( conversación ) 13:40, 29 de agosto de 2020 (UTC)
- Los eliminamos porque hay tantos, no todos los juegos los obtienen, y ningún otro medio que tenga ratings (como cine y televisión) también los incluye. Si la calificación es importante (por ejemplo, si está prohibido en un país), la cubriremos en el cuerpo. - M asem ( t ) 20:47, 29 de agosto de 2020 (UTC)
- El aspecto mundial hace que esto no sea un comienzo para mí. Un juego mundial se clasifica en varios tableros diferentes (y cambian con el tiempo). Como dice Masem, si un juego tiene algo particularmente notable en su calificación, puede prosperar. Best Wishes, Lee Vilenski ( discusión • contribuciones ) 07:39, 30 de agosto de 2020 (UTC)
- Se oponen fuertemente Las calificaciones proporcionan poco contexto. La única vez que brindan valor es cuando hay controversia en torno a ellos y los artículos de esos juegos generalmente tienen esos detalles descritos. - The Grid ( charla ) 14:20, 31 de agosto de 2020 (UTC)
¿Segundo apagón de Wikipedia?
- La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.
En caso de que no lo sepa, las transacciones de EE. UU. Con TikTok y WeChat serán prohibidas pronto. Acabo de ver un video de Vox [9] sobre cómo tal prohibición representa una amenaza para la Internet abierta. Me preguntaba si deberíamos tapar Wikipedia el día en que el sitio sea prohibido. Hicimos esto en 2012 cuando el Congreso estaba considerando SOPA y PIPA . Creo que crear conciencia sobre este tema puede ayudar a plantear problemas sobre las amenazas actuales en los Estados Unidos a la Internet abierta.
"¡Pero son las aplicaciones chinas las que están prohibidas, no Wikipedia!" - en primer lugar, esto es en los Estados Unidos, un país que durante mucho tiempo ha adoptado la Internet abierta y, en segundo lugar, el panorama de Internet en todos los países está cambiando rápidamente para adoptar la censura y bloquear la libertad de expresión. Si decidimos bloquear Wikipedia por segunda vez, ¿cuánto tiempo debemos hacerlo, qué páginas deben bloquearse (si las hay) y cuándo debemos detener el bloqueo? Queremos una Internet libre y abierta . Seguro que no a todo el mundo le gusta TikTok, pero si TikTok está prohibido en los EE. UU., ¿Quién será el próximo? ¿Google? Wikipedia? No sabemos. Y si bien pueden ser dos aplicaciones chinas, esto tendrá efectos duraderos en cómo vemos Internet.
No estoy haciendo esta propuesta a la ligera, reconozco la cantidad de interrupciones que puede causar a los lectores, editores y similares. Si esto es rechazado, lo entenderé completamente. Después de todo, se supone que no debemos promover una causa primero , pero creo que dado que lo hemos hecho antes en 2012 significa que podríamos hacerlo de nuevo. Este puede ser un caso de WP: IAR que podemos invocar solo esta vez.
Si tuviéramos que bloquear Wikipedia por segunda vez, sugeriría que se bloquee del 16 al 18 de septiembre, afectando a todas las páginas del espacio principal y del portal, excepto las páginas relacionadas con la censura y la amenaza que tiene la Internet abierta. Reconozco que puede causar muchas interrupciones a las personas que acceden a los recursos en línea, pero nos brinda lo que los wikipedistas queremos: una Internet libre y abierta donde podamos acceder al contenido de forma libre y segura. No queremos que se bloqueen los sitios web porque la gente los use para organizar ventas o boicots o para vengarse del COVID-19; al bloquear el contenido, tiene un gran impacto en la libertad de información .
No quiero que esto suene súper político, pero una Internet abierta es por lo que los wikipedistas hemos estado luchando durante los últimos 19 años. No queremos muros de pago o censura gubernamental del contenido de Internet; queremos tener la capacidad de acceder y comunicar libremente la información cuando sea necesario. A a s i m 09:30, 30 de agosto de 2020 (UTC)
- Fuertemente opuesto a todos y cada uno de los apagones ... por cualquier causa. Wikipedia no es un lugar para el activismo. No es un lugar para corregir grandes errores. Debemos mantener un punto de vista NEUTRO. Blueboar ( charla ) 12:49, 30 de agosto de 2020 (UTC)
- Oponerse por Blueboar . Jerm ( charla ) 12:54, 30 de agosto de 2020 (UTC)
- Oponte este esfuerzo a RGW. Ni siquiera es una certeza que serán prohibidos (se pueden comprar). 331dot ( charla ) 13:00, 30 de agosto de 2020 (UTC)
- Oponerse : esto no es lo mismo que las tonterías de SOPA / PIPA. Reyk YO! 13:07, 30 de agosto de 2020 (UTC)
- Los apagones deben reservarse para crisis potencialmente existenciales, considerando los enormes impactos negativos que tienen en los lectores. Usarlos para cualquier otra cosa los abarata. - Tera tix ₵ 13:09, 30 de agosto de 2020 (UTC)
- Oponerme No me opongo en principio a la acción política como proyecto cuando algo amenaza directamente nuestro trabajo. Pero "alguna aplicación" que los adolescentes usan para compartir videos de baile está bastante abajo en la lista de amenazas. G M G talk 13:15, 30 de agosto de 2020 (UTC)
- Opongo No me opongo a cualquier apagón, pero sólo debe utilizarse cuando hay una amenaza existencial para Wikipedia (o potencialmente un proyecto hermano, si tal división podría suceder). Dado que en-wiki optó en contra de un apagón en las enmiendas de derechos de autor de la UE, se necesitará una acción realmente drástica para desencadenar otro apagón. Nosebagbear ( charla ) 14:20, 30 de agosto de 2020 (UTC)
- Oponerse . Esto se vería como una protesta política y realmente debemos mantenernos al margen de la política. - RoySmith (charla) 14:24, 30 de agosto de 2020 (UTC)
- Oponerse Si bien existen riesgos existenciales en juego con las prohibiciones de TikTok / WeChat, actualmente son muy específicas y no amenazan directamente el modelo de WP. Algo como las diversas leyes de la Sección 230 y EO que se están lanzando, pero hasta ahora es difícil hacer qué efecto tienen, por lo que aún no hay necesidad de llorar lobo. - M asem ( t ) 14:30, 30 de agosto de 2020 (UTC)
- Fuerte oposición por Blueboar. - Mandruss ☎ 14:35, 30 de agosto de 2020 (UTC)
Migrar algunos usos de Template: Commons a Template: Commons categoría
Hola todos. Tenemos {{ Commons }} que proporciona enlaces generales a Commons y {{ categoría Commons }} que enlaza específicamente a categorías de Commons. Cuando se usa sin parámetros, {{ Commons }} enlaza a las páginas de búsqueda de Commons; cuando se usa con un parámetro, usa ese parámetro para vincular específicamente a esa galería o categoría de Commons. Mientras tanto, {{ categoría Commons }} cuando se usa sin un parámetro usa Wikidata para vincular a categorías Commons (donde se definen a través de vínculos a sitios en Wikidata) o el parámetro con nombre donde se proporciona (que se verifica con los vínculos a sitios de la categoría Commons en Wikidata para agregarlo a las categorías de seguimiento).
Me gustaría migrar mediante bot los usos de {{ Commons }} a {{ Commonscat }} en circunstancias como estas:
- {{ Commons }} se usa sin un parámetro (= enlaces a la página de búsqueda), pero una categoría Commons está vinculada a la página / categoría.
- {{ Commons }} enlaces a una categoría de Commons
- {{ Commons }} enlaza a una galería inexistente o redirigida, pero una categoría Commons tiene un enlace de sitio.
- Opcional: si {{ Commons }} enlaza a una galería inexistente o redirigida, sin categoría Commons, entonces a) el enlace podría eliminarse ob) el parámetro eliminado.
Esto se puede hacer como una ejecución única o con regularidad para detectar nuevos casos. Actualmente hay ~ 65k usos de {{ Commons }} (en comparación con ~ 780k usos de {{ categoría Commons }}). Si esto está bien, entonces puedo enviar una propuesta de bot: ya tengo un código pywikibot semiautomático para hacer esto que puedo convertir fácilmente en un bot, lo he estado ejecutando de forma interactiva en los últimos días, pero dada la cantidad de casos y una alta tasa de precisión, esto probablemente sea mejor como bot. (por ejemplo, para el caso 1, [10] , o para el caso 2, [11] - los casos 3 y 4 aún no están codificados). Esto es parte de mi trabajo más amplio para limpiar enwp <--> wikidata <--> enlaces de sitio comunes, puedo proporcionar más antecedentes si es necesario.
(Por cierto, no estoy seguro de si esto debería ser un RfC o simplemente una encuesta de paja, si alguien piensa que debería ser un RfC, no dude en agregar las etiquetas). Gracias. Mike Peel ( charla ) 18:17, 30 de agosto de 2020 (UTC)
- Soporte . Dos notas: 1) En Commons hay muchos cross-ns #REDIRECTs (page_is_redirect = 1) que apuntan desde galerías a categorías (intencionalmente o como restos de un movimiento de cross-ns). 2) Los gatos de destino deben comprobarse si son redireccionamientos. Están etiquetados por plantillas y no #REDIRECTed, pero se pueden detectar mejor si eres miembro de c: Category: Category redirects . - Achim ( charla ) 18:57, 30 de agosto de 2020 (UTC)
- @ Achim55 : Normalmente uso código que verifica los usos de los comunes: Plantilla: redireccionamiento de categoría y una lista de redireccionamientos conocidos a esa plantilla; puede que no los capture a todos, pero funciona de manera conservadora; si no puede encontrar la plantilla, asume que es una galería válida. Gracias. Mike Peel ( charla ) 19:06, 30 de agosto de 2020 (UTC)
- Mike , la última palabra ... debería haber sido "categoría", creo. Bueno, probar el uso de plantillas también debería funcionar, pero sugiero que verifique si su código cubre la "cascada" c: Plantilla: redirección de categoría de taxón no válida también. Saludos, Achim ( charla ) 19:19, 30 de agosto de 2020 (UTC)
- @ Achim55 : No, 'galería' es correcta, usa los enlaces de sitio para buscar categorías, por lo que solo la verificación de la galería es más complicada. Siempre estoy feliz de mejorar el código, pero eso probablemente se debata mejor en la propuesta del bot: primero debemos establecer si esto es algo que queremos hacer como comunidad. Gracias. Mike Peel ( charla ) 19:23, 30 de agosto de 2020 (UTC)
- @ Achim55 : Normalmente uso código que verifica los usos de los comunes: Plantilla: redireccionamiento de categoría y una lista de redireccionamientos conocidos a esa plantilla; puede que no los capture a todos, pero funciona de manera conservadora; si no puede encontrar la plantilla, asume que es una galería válida. Gracias. Mike Peel ( charla ) 19:06, 30 de agosto de 2020 (UTC)
Sugerencia Tengo una propuesta alternativa, algo superpuesta, que creo que logrará los mismos fines y requerirá menos edición de bots y mejorará las cosas para los lectores. Propongo convertir {{ Commons }} de nuevo en una plantilla genérica de "enlace al mejor elemento en Commons" que era antes de que cambiara la semántica de la búsqueda de Commons. Podríamos hacer que {{ Commons }} use el enlace Module: Commons , como lo hace {{ Commons-inline }}. Cuando {{ Commons }} no tiene parámetros, el enlace Módulo: Commons usaría Wikidata para encontrar uno de una galería Commons o una categoría Commons (si existe). El módulo es de "falla suave": si Wikidata es inconsistente, recurre a la búsqueda de Commons. El uso de este módulo cubriría los casos de Mike Peel (1) y (3), anteriores. Apoyo con entusiasmo el uso de un bot para manejar el caso (2) anterior (porque la intención del editor es clara: debería serlo claramente ). Apuesto a que sería un bot de una sola vez.{{Commons|Category:Foo}}
{{Commons category|Foo}}
El uso de este módulo se crea un prototipo en Template: Commons / sandbox , con casos de prueba en Template: Commons / testcases
Algunas notas adicionales para responder preguntas que puedan tener otros editores:
- Hace aproximadamente 2 años, el significado de la búsqueda de Commons cambió. Cuando había un término de búsqueda "Foo", si había una galería llamada "Foo", los lectores serían llevados directamente a esa galería. Si no, y si hubiera una categoría llamada "Foo", los lectores serían llevados directamente a esa categoría. De lo contrario, recurriría a una búsqueda genérica de "Foo". Esto fue mucho más amigable que la situación actual. Módulo: El enlace Commons (función getGalleryOrCategory) está diseñado para restaurar ese comportamiento (en la medida de lo posible), usando Wikidata. Si no puede, volverá a buscar de forma predeterminada.
- Módulo: el enlace Commons está listo para el horario de máxima audiencia. Se utiliza en más de 25.000 artículos de {{ Commons y categoría }}, {{ Commons y categoría-inline }}, {{ Commons-inline }} y {{ Sister links }}. Tiene casos de prueba y no he recibido quejas durante los últimos meses.
- Módulo: el enlace Commons es flexible y no intrusivo:
- Si se proporciona un parámetro, lo usa en lugar de buscar en Wikidata
- Busca en varios campos de Wikidata (por ejemplo, enlaces de sitio) posibles galerías y categorías: si una galería o categoría está disponible, la usa. Si Wikidata se contradice a sí mismo, se da por vencido y vuelve a la búsqueda de Commons.
- Muchas gracias a RexxS y Mike Peel por sus consejos sobre cómo construir este módulo: ¡Confié en el Módulo: WikidataIB para inspirarme!
- En caso de que Mike Peel se preguntara: si P373 está en desuso, el enlace Módulo: Commons seguiría funcionando sin errores. Utiliza P373 como una posible fuente de enlaces de galería, pero si está vacío o eliminado, simplemente encontrará menos galerías.
Creo que el enlace Module: Commons cumple la mayoría de los objetivos de la propuesta de Mike, al mismo tiempo que se actualiza automáticamente cuando cambian los enlaces de sitio de Commons (p. Ej.).
¿Qué piensan otros editores de esto? - hike395 ( charla ) 19:44, 30 de agosto de 2020 (UTC)
- @ Hike395 : Esperaba mantener esto enfocado en el tema específico de si usar las plantillas {{ Commons }} frente a {{ categoría Commons }}, ya que ese es un paso práctico que podemos tomar ahora. Si vamos a convertir esto en una discusión más amplia, me gustaría que usáramos una plantilla única que vincule a la galería y / o categoría, ya que están disponibles a través de los vínculos a sitios en Wikidata, posiblemente a través del vínculo Módulo: Comunes si @ RexxS : puede confirmar que esto es compatible con el Módulo: WikidataIB ). Gracias. Mike Peel ( charla ) 20:02, 30 de agosto de 2020 (UTC)
- @ Mike Peel : Mirando el enlace Módulo: Commons , puedo confirmar que interactúa con Wikidata de la misma manera que lo hace WikidataIB. Esencialmente, agrega múltiples funciones de utilidad para trabajar con categorías y galerías en Commons, y dos llamadas principales para obtener la Categoría y la Galería asociadas, respectivamente, en Wikitext. - RexxS ( conversación ) 23:11, 30 de agosto de 2020 (UTC)
- @ Mike Peel : Disculpas por posiblemente aleatorizar la discusión. Algunas notas más:
- Si logramos un consenso en torno a esto, podemos promover Template: Commons / sandbox a Template: Commons de inmediato y lograr parte de lo que desea de un bot ejecutado de inmediato, sin esperar. Es un paso práctico que podemos dar hoy. En este caso, {{ Commons }} se convertiría en lo que está sugiriendo (una "plantilla que enlaza con la galería o la categoría, ya que están disponibles a través de los enlaces de sitio en Wikidata"), con comprobaciones adicionales de otras propiedades de respaldo y coherencia. .
- En marzo, RexxS realizó generosamente una revisión del código para el enlace Module: Commons y no vio ningún problema al entrar en producción. Mike: ¿Tenías preocupaciones específicas sobre cómo el enlace Módulo: Commons era diferente al Módulo: WikidataIB ? Hay cuatro puntos de entrada principales: getGallery, getCategory, getGalleryOrCategory (devuelve uno), getGalleryAndCategory (devuelve ambos). En lugar de comprobar Wikidata en serie, rescatando después de encontrar el primer elemento, el enlace Módulo: Commons se ve en todos los mismos lugares que Módulo: WikidataIB , y no devuelve un enlace Commons si se encuentra alguna inconsistencia.
- En esa misma discusión , Mike planteó una idea interesante para combinar plantillas de Commons. ¿Podemos aplazar esa discusión a favor de una simple llamada al módulo: enlace de Commons en {{ Commons }}? Como dijiste, la llamada del módulo es una idea práctica simple que podemos implementar hoy. Las plantillas de Commons siempre se pueden fusionar más tarde, si logramos consenso.
- ¡Más comentarios / sugerencias / problemas son bienvenidos! - hike395 ( charla ) 23:09, 30 de agosto de 2020 (UTC)
- @ Hike395 : Mirando esto con más detalle, creo que los cambios en Template: Commons / sandbox son una mejora útil para reducir la cantidad de enlaces defectuosos, y creo que debería hacer ese cambio de inmediato (puedo publicarlo si no no tiene los permisos para hacerlo). Sin embargo, {{ Commons cat }} incluye las categorías de seguimiento, en particular para los casos en los que no hay un parámetro definido ni un enlace de sitio en Wikidata (= enlace a la búsqueda en esta plantilla), y donde el texto local no coincide con Wikidata. Estos son realmente útiles para el mantenimiento, pero se vuelven más complejos de manejar cuando tiene tanto categorías como galerías (en particular si no sabe a qué editor desea vincular). Pi bot también está configurado para mantener los enlaces a las categorías, lo cual es parte de la razón por la que quiero migrar los casos para usar {{ Commons category }} siempre que sea posible, sin eliminar los enlaces a las galerías. A largo plazo, me gustaría vernos usando ambas plantillas sin parámetros (solo usando Wikidata), y enlazando a la galería y la categoría (y tal vez categorías relacionadas), pero esa es una discusión separada.
- En pocas palabras, creo que su trabajo es bueno y debe hacerse en vivo, pero es paralelo a la propuesta específica que he presentado aquí. Creo que ambos podrían avanzar en paralelo. Gracias. Mike Peel ( charla ) 19:01, 1 de septiembre de 2020 (UTC)
- @ Mike Peel : Disculpas por posiblemente aleatorizar la discusión. Algunas notas más:
- @ Mike Peel : ¡Gracias! Lo acabo de hacer funcionar. Estoy de acuerdo en que el enlace Módulo: Comunes es complementario a su propuesta. Su propuesta contiene un valioso conjunto de limpiezas que creo que deberíamos implementar. Creo que en este momento solo estamos discutiendo los detalles de las limpiezas.
- Estoy más que feliz de implementar la lógica de la categoría de seguimiento de {{ categoría Commons }} en el enlace Módulo: Commons . Eso debería ser fácil en Lua. Si está de acuerdo, puedo agregar esa lógica a {{ Commons }}. También puedo exponerlo como un punto de entrada, por lo que podemos hacer que {{ categoría Commons }} sea un poco más compacta (si lo desea). Comenzaré a trabajar en eso en el Módulo: vínculo común / caja de arena . Después de implementar eso, no necesitaremos cambiar la plantilla para obtener las categorías de seguimiento.
- Creo que {{ Commons }} y {{ Commons categoría }} expresan una intención diferente del editor. El último significa "Realmente quiero vincular a una categoría", mientras que el primero significa "Quiero lo mejor de Commons, de algún tipo". Solo estoy tratando de tener mucho cuidado con que un bot realice cambios masivos que puedan alterar la intención del editor. Permítanme desglosar los posibles casos que ha descrito y hacer una sugerencia que debería preservar la intención del editor.
- {{ Commons }} tiene un primer parámetro que es una categoría --- claramente muévase a {{ Commons categoría }}
- {{ Commons }} tiene un primer parámetro que es un redireccionamiento a una categoría --- es muy probable que mover a {{ Commons categoría }} sea correcto
- {{ Commons }} tiene un primer parámetro que no existe en Commons. Hay dos posibilidades:
- El editor cometió un error (probablemente) --- la respuesta correcta es eliminar el primer parámetro y dejar que el enlace Module: Commons haga su magia de Wikidata.
- El editor puede haber tenido la intención de invocar una búsqueda de Commons (poco probable, pero posible)
- ¿Podríamos simplemente eliminar el primer parámetro e ignorar el caso poco probable? O puedo agregar un
|fallback=
parámetro a {{ Commons }} y al enlace Module: Commons , y hacer que la búsqueda Commons se ejecute después de que Wikidata falle. ¿Qué opinan otros editores?
- {{ Commons }} no tiene un primer parámetro --- Ahora que estamos usando el enlace Module: Commons , que está diseñado específicamente para este caso, dejaría este caso solo. (Especialmente después de agregar las categorías de seguimiento adicionales).
- Para resumir, apoyo el uso de un bot en mis casos (1) y (2), arriba, me opongo al uso de un bot en mi caso (4), y discutamos mi caso (3). Me pondré manos a la obra en las categorías de seguimiento.
- ¿Qué opinan otros editores? ¿Miguel? - hike395 ( charla ) 14:37, 2 de septiembre de 2020 (UTC)
- @ Hike395 : Creo que estamos de acuerdo con el primero (mi número 2) y el segundo que forma parte de mi número 3. Sus puntos tercero y cuarto asumen que el enlace a la búsqueda era correcto (excluyo automáticamente cualquier enlace a una galería existente aquí), no estoy seguro de que sea una suposición razonable. Particularmente en las categorías, creo que tiene sentido vincular a la categoría Commons en lugar de a los resultados de búsqueda, donde (y solo donde) existe dicha categoría. Si no existe una categoría con vínculos a sitios de este tipo, mi propuesta no alteraría esos casos. Quizás la pregunta general aquí es: ¿queremos vincular a la búsqueda en lugar de una categoría común existente sobre el tema? Gracias. Mike Peel ( charla ) 17:55, 2 de septiembre de 2020 (UTC)
- @ Mike Peel : Estoy de acuerdo en que los enlaces de búsqueda son una mala experiencia para el usuario. Sin embargo, ahora que el enlace Module: Commons se usa en {{ Commons }}, mi caso # 4 ya no usa enlaces de búsqueda. Mi caso # 4 ahora va directamente a la categoría Commons (si no hay una galería Commons correspondiente, de lo contrario, la usará). He escrito (pero aún no he probado) la lógica de la categoría de seguimiento en Lua. Pronto no habrá ninguna razón de peso para trasladar el caso n. ° 4 a {{ categoría Commons }} (creo). - hike395 ( charla ) 19:16, 2 de septiembre de 2020 (UTC) I
- @ Hike395 : Está bien, eso es bueno. Entonces, la pregunta es, para los casos en los que la plantilla se vincula únicamente a categorías de Comunes, si es mejor usar {{ Categoría de Comunes }} para dejar en claro que es un enlace a una categoría de Comunes. Luego, mantenemos la galería y la categoría como mantenimiento por separado. Pero la otra forma de verlo es que es el primer paso para fusionarse en una sola plantilla de Commons que lo clasifica automáticamente. Gracias. Mike Peel ( charla ) 17:34, 3 de septiembre de 2020 (UTC)
- @ Mike Peel : Estoy de acuerdo en que los enlaces de búsqueda son una mala experiencia para el usuario. Sin embargo, ahora que el enlace Module: Commons se usa en {{ Commons }}, mi caso # 4 ya no usa enlaces de búsqueda. Mi caso # 4 ahora va directamente a la categoría Commons (si no hay una galería Commons correspondiente, de lo contrario, la usará). He escrito (pero aún no he probado) la lógica de la categoría de seguimiento en Lua. Pronto no habrá ninguna razón de peso para trasladar el caso n. ° 4 a {{ categoría Commons }} (creo). - hike395 ( charla ) 19:16, 2 de septiembre de 2020 (UTC) I
- @ Hike395 : Creo que estamos de acuerdo con el primero (mi número 2) y el segundo que forma parte de mi número 3. Sus puntos tercero y cuarto asumen que el enlace a la búsqueda era correcto (excluyo automáticamente cualquier enlace a una galería existente aquí), no estoy seguro de que sea una suposición razonable. Particularmente en las categorías, creo que tiene sentido vincular a la categoría Commons en lugar de a los resultados de búsqueda, donde (y solo donde) existe dicha categoría. Si no existe una categoría con vínculos a sitios de este tipo, mi propuesta no alteraría esos casos. Quizás la pregunta general aquí es: ¿queremos vincular a la búsqueda en lugar de una categoría común existente sobre el tema? Gracias. Mike Peel ( charla ) 17:55, 2 de septiembre de 2020 (UTC)
Cajas de sucesión para presidentes de EE. UU.
A continuación de la discusión que comenzó aquí:
Charla: Donald Trump # ¿Qué pasó con las cajas de sucesión?
¿Cómo se siente la comunidad acerca de las cajas de sucesión y su inclusión en los artículos sobre presidentes de Estados Unidos específicamente? Las siguientes tres opciones se presentaron en la página de discusión anterior:
- Las casillas de sucesión deben incluirse en todos los BLP de los presidentes de EE. UU.
- Las casillas de sucesión deben omitirse en todos los BLP de los presidentes de EE. UU.
- Una talla no sirve para todos. La consistencia entre artículos es menos importante que la flexibilidad. Decidir caso por caso a nivel de artículo.
Realmente creo que ayudan a la navegación entre artículos, aunque a menudo se pueden recortar para evitar elementos triviales, y si son demasiado grandes, se pueden contraer en el cuadro Oficinas y distinciones. De esa manera, si los buscas, están ahí, pero si no, no ocupan mucho espacio en la parte inferior del artículo. ScottishNardualElf ( charla ) 08:55, 1 de septiembre de 2020 (UTC)
- 2 - La información allí contenida es algo redundante con los campos Precedido por y Sucedido por , aunque es mucho menos visible y accesible al final del artículo. La poca evidencia anecdótica que tenemos (de editores que solían ser solo lectores) sugiere que los lectores rara vez o nunca usan las cajas de sucesión. En Donald Trump , las cajas se eliminaron después de una breve discusión en diciembre de 2018, y los únicos argumentos en contra de eso han sido que los BLP de los presidentes de EE. UU. Deben ser consistentes. Nadie ha intentado siquiera argumentar que las cajas realmente benefician a los lectores lo suficiente como para justificar el espacio requerido, y creo que sería un caso muy difícil de defender. Bien, hagamos que los BLP de los presidentes de EE. UU. Sean consistentes. - Mandruss ☎ 09:26, 1 de septiembre de 2020 (UTC)
{{Infobox officeholder}}
- 2 - los cuadros de sucesión son una herramienta de navegación obsoleta en en.wiki. Tenemos, como Mandruss señaló anteriormente, los campos relevantes en el cuadro de información, pero también plantillas de navegación como {{ Presidentes de EE . UU. }} Que ya muestran la lista completa. Las cajas de sucesión solo agregan desorden, ya que son mucho más grandes y no ofrecen ningún valor adicional. - Gonnym ( charla ) 10:28, 1 de septiembre de 2020 (UTC)
- 1 o 2 , pero esto debe incluir todas las biografías de los nominados a la presidencia y vicepresidencia de EE. UU. GoodDay ( charla ) 14:16, 1 de septiembre de 2020 (UTC)
Aplanar sus cajas de sucesión y / o abdominales
Así que he sugerido esto antes, pero aquí está mi maqueta visual inicial. Lo que hoy conocemos como "cajas de sucesión" debería aplanarse para tener un aspecto similar al siguiente:
Idealmente, la plantilla también leería los datos de cada fila (nombres, orden, fechas, anotaciones, lo que sea) buscando {{PAGENAME}}
en listas centralizadas (por ejemplo, tituladas Module:Succession/President of the United States
) y formateando los resultados de la búsqueda en consecuencia. Entonces, la sintaxis de llamada podría reducirse a algo como esto (con varias abreviaturas permitidas):
{{sucesion navbox | Senado de Illinois | Senado de los Estados Unidos | Presidente de los Estados Unidos}}
Posiciones no reconocidas como las Community Organizer (Chicago)
que serían ignoradas e imposibles de agregar casualmente para los novatos. Tal sistema reduciría en gran medida el desperdicio de pantalla, permitiría un control más estricto sobre la precisión y protegería contra la basura aleatoria que atraen universalmente las cajas de sucesión existentes. Probablemente podría crearlo en unos días, si hay interés. - cobaltcigs 12:11, 1 de septiembre de 2020 (UTC)
Teniendo en cuenta que las cajas existentes están colapsadas, no creo que esto sea realmente relevante para esta discusión (y se siente como una distracción, para ser honesto). Por lo que he visto, los argumentos en contra de las cajas no son que ocupen demasiado espacio en la pantalla cuando un lector las expande temporalmente.No hay razón para creer que esto sería más necesario o utilizado que las cajas existentes. - Mandruss ☎ 12:38, 1 de septiembre de 2020 (UTC) (Huelga después de la discusión posterior.) - Mandruss ☎ 13:35, 1 de septiembre de 2020 (UTC)- Quizás Usuario: Gonnym aclararía
Los cuadros de sucesión solo agregan desorden, ya que son mucho más grandes
a la luz del hecho de que están colapsados, pero mi referencia ael espacio requerido
era para otros tipos de espacio: tamaño de archivo, tamaño de inclusión posterior a la expansión, espacio en la ventana de edición e incluso el espacio de pantalla requerido para la barra de contracción. Si las cajas se usan con poca frecuencia, incluso esas cosas relativamente menores no están justificadas. El desorden innecesario masivo suele ser una acumulación gradual de cosas relativamente menores como esta: "oye, una barra de colapso más no hará daño", y solo podemos abordarlas una a la vez. - Mandruss ☎ 13:03, 1 de septiembre de 2020 (UTC)- Una plantilla no debería ser enorme incluso cuando se gasta si no es necesario. Compare el tamaño de la sección de sucesión (Oficinas y distinciones) con Plantilla: Barack Obama . Mire cuántos datos de enlace tiene el navbox en comparación con el de sucesión y, sin embargo, el de sucesión es mucho más grande y duplica la información presentada en otras partes del artículo, incluso junto a él con {{ Presidentes de EE . UU. }}. - Gonnym ( charla ) 13:17, 1 de septiembre de 2020 (UTC)
- @ Gonnym : En ese caso, la propuesta de cobaltcigs parecería abordar al menos algunas de sus preocupaciones. Entonces, ¿lo apoyaría como una solución? - Mandruss ☎ 13:23, 1 de septiembre de 2020 (UTC)
- No en realidad no. Es mejor que las plantillas de sucesión actuales, pero aún no es necesario ya que sigue duplicando datos junto a él. Usando el ejemplo anterior, está duplicando {{ Presidentes de EE . UU. }} Y {{ Senadores de EE . UU. De Illinois }} y el escaño del Distrito 13 aparentemente no es lo suficientemente importante como para justificar una plantilla de navegación. Y nuevamente, los 3 son las primeras piezas de información inmediatamente después de su imagen en el cuadro de información. - Gonnym ( charla ) 13:30, 1 de septiembre de 2020 (UTC)
- Muy bien, todavía estoy aprendiendo las cuerdas aquí. ScottishNardualElf ( charla ) 22:25, 1 de septiembre de 2020 (UTC)
- @ ScottishNardualElf : Es posible que reciba más atención sobre este tema si convierte esta discusión en un RFC. GoodDay ( charla ) 15:33, 3 de septiembre de 2020 (UTC)
- Muy bien, todavía estoy aprendiendo las cuerdas aquí. ScottishNardualElf ( charla ) 22:25, 1 de septiembre de 2020 (UTC)
- No en realidad no. Es mejor que las plantillas de sucesión actuales, pero aún no es necesario ya que sigue duplicando datos junto a él. Usando el ejemplo anterior, está duplicando {{ Presidentes de EE . UU. }} Y {{ Senadores de EE . UU. De Illinois }} y el escaño del Distrito 13 aparentemente no es lo suficientemente importante como para justificar una plantilla de navegación. Y nuevamente, los 3 son las primeras piezas de información inmediatamente después de su imagen en el cuadro de información. - Gonnym ( charla ) 13:30, 1 de septiembre de 2020 (UTC)
- @ Gonnym : En ese caso, la propuesta de cobaltcigs parecería abordar al menos algunas de sus preocupaciones. Entonces, ¿lo apoyaría como una solución? - Mandruss ☎ 13:23, 1 de septiembre de 2020 (UTC)
- Una plantilla no debería ser enorme incluso cuando se gasta si no es necesario. Compare el tamaño de la sección de sucesión (Oficinas y distinciones) con Plantilla: Barack Obama . Mire cuántos datos de enlace tiene el navbox en comparación con el de sucesión y, sin embargo, el de sucesión es mucho más grande y duplica la información presentada en otras partes del artículo, incluso junto a él con {{ Presidentes de EE . UU. }}. - Gonnym ( charla ) 13:17, 1 de septiembre de 2020 (UTC)
Ampliación de alcance: cajas de sucesión
Esta pregunta debería ampliarse para incluir todas las biografías de los candidatos a la presidencia y vicepresidencia de EE. UU. GoodDay ( charla ) 14:13, 1 de septiembre de 2020 (UTC)
- Claro, pero ¿por qué detenerse ahí? ¿Qué pasa con el uso de las mismas casillas en los BLP para otros titulares de oficinas en EE. UU.? ¿Qué pasa con los titulares de cargos no estadounidenses? Si está expandiendo el alcance, el único lugar lógico para dejar de expandirse sería incluir todos los usos de los recuadros en cualquier lugar de la enciclopedia. Esa es una pregunta mucho más amplia, y antes de que te des cuenta, tienes una discusión de meses, muy posiblemente todo el tiempo perdido debido a un resultado sin consenso. Digo que podemos abordar esto en piezas más pequeñas sin dañar indebidamente la enciclopedia, pero cualquier consenso aquí sería un factor en futuras discusiones sobre otras piezas. Si llegamos a un consenso para la opción 1, probablemente no habrá discusiones futuras de todos modos. - Mandruss ☎ 14:44, 1 de septiembre de 2020 (UTC)
- No fue mi decisión eliminar las casillas de sucesión en Donald Trump , por lo que ese artículo no está sincronizado con los demás. GoodDay ( charla ) 15:38, 1 de septiembre de 2020 (UTC)
- ¡¿¿Eso otra vez??! Tienes razón, no fue tu decisión. Fue un consenso local no excluido por un consenso de la comunidad , como se les explicó más de una vez. Se argumentó el factor de coherencia entre artículos, y no fue suficiente para influir en el consenso hacia el mantenimiento. Por favor, deje de hacerme seguir explicándole cómo funciona Wikipedia, ha estado presente demasiado tiempo para eso. Te estás volviendo disruptivo. - Mandruss ☎ 15:49, 1 de septiembre de 2020 (UTC)
- No me interesa meterme en insultos personales contigo, así que no sigamos ese camino. GoodDay ( charla ) 16:13, 1 de septiembre de 2020 (UTC)
- ¡¿¿Eso otra vez??! Tienes razón, no fue tu decisión. Fue un consenso local no excluido por un consenso de la comunidad , como se les explicó más de una vez. Se argumentó el factor de coherencia entre artículos, y no fue suficiente para influir en el consenso hacia el mantenimiento. Por favor, deje de hacerme seguir explicándole cómo funciona Wikipedia, ha estado presente demasiado tiempo para eso. Te estás volviendo disruptivo. - Mandruss ☎ 15:49, 1 de septiembre de 2020 (UTC)
- No fue mi decisión eliminar las casillas de sucesión en Donald Trump , por lo que ese artículo no está sincronizado con los demás. GoodDay ( charla ) 15:38, 1 de septiembre de 2020 (UTC)
Los usuarios bloqueados globalmente deben tener sus nombres de usuario tachados
Hay un gadget ( Especial: Preferencias # mw-prefsection-gadgets / Apariencia / Tachar los nombres de usuario que han sido bloqueados) que ataca los nombres de usuario si han sido bloqueados. Me parece (obvio) que debería hacer lo mismo para los usuarios bloqueados globalmente. ¿Se ha hablado de esto antes? ¿Hay alguna razón por la que no lo hace, aparte de que aún no se ha implementado? - RoySmith (charla) 13:22, 1 de septiembre de 2020 (UTC)
- RoySmith , hay una discusión / solicitud lenta en la charla de MediaWiki: Gadget-markblocked.js # Usuarios bloqueados y bloqueados
globalmente Cabayi ( charla ) 13:54, 1 de septiembre de 2020 (UTC)
- Ah, guay. Abrí T261752 , como se sugiere en ese hilo. - RoySmith (charla) 14:08, 1 de septiembre de 2020 (UTC)
Páginas de conversación
En las páginas de discusión de los artículos, a menudo se dice "La página de discusión es para la discusión del artículo en Wikipedia, no para la discusión general del tema". Sin embargo, si uno lee lo que se dice en las páginas de discusión, muy a menudo la charla se centra más en el tema que en el artículo. Aparte de abolir por completo las páginas de discusión, lo que sería una propuesta bastante radical, ¿deberíamos permitir la discusión del tema? Vorbee ( charla ) 06:05, 4 de septiembre de 2020 (UTC)
- En la primera toma, diría que no. La guía es una herramienta viable para intervenir en discusiones disruptivas en las páginas de discusión. En todo caso, probablemente debería actualizarse a una política citable en lugar de desecharse. Van Isaac WS cont 06:17, 4 de septiembre de 2020 (UTC)
- Esto siempre me ha confundido. Si quiero buscar opiniones sobre si agregar algo al artículo, esto debe resultar en una discusión del tema, más que del artículo. Si quiero sugerir que alguien con los conocimientos necesarios sobre la materia pueda agregar algo a un artículo, lo mismo ocurre. Etc. Downsize43 ( charla ) 06:59, 4 de septiembre de 2020 (UTC)
- Creo que el problema se trata de hasta qué punto algunos usuarios pueden llegar a la página de discusión de un artículo e iniciar una discusión sobre el tema (ofreciendo opiniones, tratando la página como un foro), en comparación con cuando un hilo específico relacionado con el contenido se amplía en alcance a conviértase más en una discusión general. Estoy de acuerdo en que una discusión más amplia del tema a menudo es inevitable y, lo que es más importante, puede ser beneficioso para una discusión genuina relacionada con el contenido, porque a menudo se necesita contexto en lugar de enfocarse en un punto aislado. He visto a editores cerrar la variedad de chat más flagrante, citando WP: NOTFORUM (# 4), que es muy sensato. A menos que haya algunos ejemplos urgentes, diría que la guía funciona bien y se aplica bien. JG66 ( charla ) 07:19, 4 de septiembre de 2020 (UTC)
Gracias por sus amables y útiles comentarios. Veo que este tema ya se discute en Wikipedia: propuestas perennes , en la Sección 3.4. Vorbee ( charla ) 07:48, 4 de septiembre de 2020 (UTC)
Agregar el Asistente para editar solicitudes a varias páginas de información y políticas
Algunos usuarios con un conflicto de intereses o a los que se les paga para editar tienen dificultades para formatear correctamente las solicitudes de edición. El WP: Modificación de una petición Asistente maneja el formato de forma automática, y se supone que animar a la redacción adecuada de las solicitudes. ¿Debería mencionarse esta herramienta en las páginas de política e información sobre WP: Conflicto de intereses y edición pagada? En concreto, propongo enlazarlo en estas páginas:
- WP: Declaración de contribución pagada # Directriz de conflicto de intereses ,
- en la directriz WP: COI siempre que se mencione la plantilla {{ request edit }},
- en el WP: Solicitud de edición de conflicto de intereses simple , y
- en WP: Editar solicitudes .
Los comentarios también son bienvenidos sobre las mejoras del asistente en sí.
Sam-2727 ( conversación ) 20:02, 4 de septiembre de 2020 (UTC)
- ¡No tenía ni idea de que esto existiera! De hecho, sugiero agregarlo también a las páginas de conversación, de alguna manera Nosebagbear ( charla ) 14:53, 5 de septiembre de 2020 (UTC)