De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Atajos

Aquí se discuten nuevas propuestas. Antes de enviar :

Las discusiones se archivan automáticamente después de permanecer inactivas durante nueve días.

«Archivos , 156 , 157 , 158 , 159 , 160 , 161 , 162 , 163 , 164 , 165 , 166 , 167 , 168 , 169 , 170 , 171 , 172 , 173 , 174 , 175 , 176

RfC: ¿Qué hacer con los enlaces de categoría a Commons? [ editar ]

¿Qué debemos hacer con los enlaces a Commons en categorías? Mike Peel ( charla ) 09:23, 12 de diciembre de 2020 (UTC)

Hola a todos. Actualmente, vinculamos las categorías aquí a las categorías de Wikimedia Commons usando {{ categoría Commons }}. Durante los últimos años, hemos estado trabajando en sincronizar los enlaces a las categorías de Commons entre enwp y Wikidata , y para el espacio de nombres de Categoría, estos ahora están completamente sincronizados. Estos enlaces usan enlaces de sitio en Wikidata, que son robustos contra el vandalismo (debe existir una categoría de Commons para enlazar a sitios), y estos también coinciden con el enlace de la barra lateral a Commons. También se utilizan para mostrar enlaces a enwp desde las categorías de Commons (tanto en la barra lateral como en los cuadros de información allí).

En 2018 publiqué un RfC para cambiar al uso de Wikidata para enlaces interwiki a Wikimedia Commons , lo que llevó a la aprobación condicional para implementar los cambios aquí, y la creación de un nuevo conjunto de categorías de seguimiento en Categoría: categorías de seguimiento de Wikidata de categoría Commons . Un RfC posterior en 2019 sobre la eliminación de enlaces definidos localmente a las categorías de Commons si coinciden con los enlaces de sitio de Wikidata resultó en un consenso para eliminar los enlaces definidos localmente a Commons.

Me gustaría volver a examinar esto, ya que se aplica solo a las categorías (es decir, esta propuesta no se aplica a los artículos). En algún momento futuro, esto también se puede aplicar a los artículos, pero para aquellos debemos solucionar el problema que hace que los enlaces de sitio de Commons no aparezcan en la barra lateral (en la Encuesta de la lista de deseos de la comunidad 2021) , y hay ~ 15k artículos que no lo son. sincronizado con Wikidata todavía (casos con, por ejemplo, enlaces múltiples, no coincidentes o fuera de lugar) de 560k artículos. Estos no son problemas para los enlaces en el espacio de nombres de Categoría, que ahora están completamente sincronizados con Wikidata.

Cambios en los enlaces actuales

Sugiero las siguientes opciones para el uso de {{ categoría Commons }}, que solo se aplicaría en el espacio de nombres de la categoría :

A1. Elimina {{ categoría Commons }} y solo tienes el enlace de la barra lateral. Esta es la opción más fácil de mantener aquí, ya que MediaWiki la mostrará automáticamente cuando esté disponible. Esto afectaría a unas 310.000 categorías (las categorías de seguimiento enumeradas en A2 y A3). Un ejemplo de cómo se vería el enlace Commons después de este cambio es Categoría: 1817 en Vermont .
A2. Elimine los enlaces definidos localmente de las categorías , es decir, {{Commons category|Example}}-> {{Commons category}}. Este es el segundo más fácil de mantener, ya que, por ejemplo, los cambios de nombre de las categorías se actualizarán automáticamente. Los enlaces definidos manualmente solo se eliminarían cuando coincidan con el enlace de sitio de Commons en Wikidata, por lo que esto también permitiría anulaciones locales. Esto afectaría alrededor de 290k categorías en Categoría: el enlace de la categoría Commons está en Wikidata . Un ejemplo de cómo se vería el enlace Commons después de este cambio es Categoría: modelado de datos .
A3. Defina siempre el enlace localmente , es decir, {{Commons category}}-> {{Commons category|Example}}. Este es el más difícil de mantener, ya que requiere bots o ediciones manuales cuando cambia el enlace. Esto afectaría a alrededor de 20.000 categorías en Categoría: enlace de categoría Commons de Wikidata . Un ejemplo de cómo se vería el enlace Commons después de este cambio es Categoría: Cuerpos de agua del Líbano .
Agregar nuevos enlaces

También propongo:

B. Bot-agregando {{ categoría Commons }} donde un enlace de sitio de categoría Commons está disponible en Wikidata

Se han agregado muchos enlaces entre Wikidata y Commons en los últimos años (ahora totalizan más de 3 millones de enlaces). Si optamos por (A2) o (A3) arriba, la adición de bots aumentaría significativamente la cantidad de enlaces a Commons. Estos enlaces ya están disponibles en la barra lateral, por lo que si buscamos (A1) arriba, esto no es necesario. Mike Peel ( charla ) 19:52, 11 de diciembre de 2020 (UTC)

Discusión (enlaces de categoría de Comunes) [ editar ]

Sugiero votar por A1, A2 o A3 y decir sí / no a B. Si llegamos a un consenso para cualquiera de estas opciones, codificaré un bot para implementarlo y lo propondré en Wikipedia: el bot solicita una discusión final antes de la implementación. Gracias. Mike Peel ( charla ) 19:52, 11 de diciembre de 2020 (UTC)

No está claro en el RFC tal como está escrito qué opciones aún nos permitirían personalizar el texto mostrado y si podríamos vincularnos a múltiples categorías, las cuales son algo que surge con bastante frecuencia (Commons tiene una ligera tendencia a dividir categorías, por lo que queremos proporciona enlaces a más de uno, y tiene una fuerte tendencia a dar a las categorías nombres realmente peculiares que no concuerdan con el nombre común en inglés). Me inclinaría fuertemente a rechazar cualquier opción que no nos permita, como mínimo, agregar texto explicativo al enlace (por ejemplo, para la biografía de un arquitecto, tener un enlace para los retratos del sujeto y un enlace para las imágenes de sus edificios). , claramente etiquetado cuál es cuál). -  Iridiscente 20:15, 11 de diciembre de 2020 (UTC)
@ Iridiscente : Son casos raros en las categorías (pero algo más común en los artículos, lo cual está fuera del alcance de este RfC). Puedo implementar algo para A2 que continuará permitiendo mostrar texto personalizado si es realmente necesario, pero que se puede usar fácilmente para engañar al lector . De todos modos, vincular a varias categorías nunca tiene sentido, ya que puede vincular directamente a la categoría adecuada desde "Categoría: Edificios por X", o simplemente vincular a "Categoría: X" para el arquitecto, y los lectores pueden ver las subcategorías en Commons para el resto, o puede mejorar las categorías en Commons. Gracias. Mike Peel ( charla ) 21:02, 11 de diciembre de 2020 (UTC)
PD, ¿esos enlaces que faltan intencionalmente están anotados / explicados en alguna parte, por favor? Si no es así, ¿quizás podrían notarse de alguna manera? Gracias. Mike Peel ( charla ) 21:34, 11 de diciembre de 2020 (UTC)

@ Mike Peel : ¿cuál es su declaración breve y neutral ? Con más de 4500 bytes, la declaración anterior (desde la etiqueta hasta la siguiente marca de tiempo) es demasiado larga para que la maneje Legobot  ( talk · contribs ), por lo que no se muestra correctamente en Wikipedia: solicitudes de comentarios / problemas técnicos de Wikipedia y Plantillas . - Red rose64 🌹 ( charla ) 23:37, 11 de diciembre de 2020 (UTC){{rfc}} 

@ Redrose64 : El título era un poco el resumen, lo parafraseé justo debajo de la etiqueta RfC del bot. Gracias. Mike Peel ( charla ) 09:23, 12 de diciembre de 2020 (UTC)

Solo para tener en cuenta, he publicado una nota neutral sobre este RfC en commons: Commons: Village_pump # Commons_links_from_enwp_categories ( diff ), ya que esto se relaciona directamente con Commons. Gracias. Mike Peel ( charla ) 20:11, 12 de diciembre de 2020 (UTC)

  • No estoy seguro de por qué se archivó el bot mientras aún se estaba ejecutando, lo desarchivé manualmente. Gracias. Mike Peel ( charla ) 13:04, 31 de diciembre de 2020 (UTC)
    tardío @ Mike Peel : Se archivó a las 02:40, 30 de diciembre de 2020 (UTC) porque no había habido publicaciones desde las 18:17, 20 de diciembre de 2020 (UTC), y la configuración de archivo (que está en la parte superior de esta página ) incluyen el parámetro , lo que significa que cualquier hilo que no haya tenido nuevas publicaciones durante al menos nueve días es elegible para el archivo. Los bots de archivo no pueden saber si una discusión se está ejecutando o no, simplemente miran la marca de tiempo más reciente. - Red rose64 🌹 ( charla ) 20:11, 17 de enero de 2021 (UTC){{User:MiszaBot/config}}|algo=old(9d)
  • Solo para tener en cuenta que solicité un cierre para esto en Wikipedia: Tablón de anuncios de los administradores / Solicitudes de cierre . Gracias. Mike Peel ( charla ) 12:59, 22 de enero de 2021 (UTC)
    • Aún está pendiente que alguien cierre esto ... Gracias. Mike Peel ( charla ) 11:34, 2 de febrero de 2021 (UTC)
      • Ídem. Mike Peel ( charla ) 21:12, 8 de febrero de 2021 (UTC)
        • Aún así ... Mike Peel ( charla ) 19:27, 15 de febrero de 2021 (UTC)
          • El sonido de los grillos es agradable ... Gracias. Mike Peel ( charla ) 18:22, 20 de febrero de 2021 (UTC)
            • ... Mike Peel ( charla ) 20:21, 27 de febrero de 2021 (UTC)
              @ Mike Peel : ¿ Hola? 🐔 ¡  Chicdat   Bawk para mí! 11:16, 5 de marzo de 2021 (UTC)
              @ Chicdat : Hola, esperando a que alguien (normalmente un administrador no involucrado) cierre este RfC ... Gracias. Mike Peel ( charla ) 11:50, 5 de marzo de 2021 (UTC)
              WP: ANC está enormemente atrasada. Algunos usuarios han estado esperando durante meses para cerrar las discusiones. ¿Cuántos administradores activos hay que no están involucrados en esta discusión, ven WP: ANC y trabajan especial y activamente en el cierre de la discusión? 🐔 ¡  Chicdat   Bawk para mí! 11:56, 5 de marzo de 2021 (UTC)
              Esperaba seguir ese proceso, pero tal vez @ AGK y Wugapodes : podrían considerar cerrar esto, ya que cerraron las RfC anteriores sobre este tema al que me vinculé anteriormente. Gracias. Mike Peel ( charla ) 18:37, 5 de marzo de 2021 (UTC)
              Segura de que tengo unos minutos - Wug · a · po · des 18:56 5 de marzo 2021 (UTC)

Encuesta (enlaces de categoría Commons) [ editar ]

Los enlaces de la categoría Commons deben eliminarse (o no agregarse) excepto cuando sea necesaria una anulación manual para vincular correctamente a Commons. Un resumen precede a la discusión. - Wug · a · po · des 19:38 5 de marzo 2021 (UTC)
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.

Para empezar, hay un consenso en contra de A1, por lo que no deberíamos eliminar {{ categoría Commons }}, sino agregarlo al enlace de la barra lateral. Los editores dan varias razones para esto, pero los puntos principales son que los lectores móviles no pueden ver nuestra barra lateral (lo que hace que la plantilla de gato común sea su único enlace) y los lectores de escritorio no prestan mucha atención a nuestra barra lateral (lo que hace que la plantilla de gato común sea su principal enlace interwiki). Esta opinión no es unánime, y los tres editores que apoyan la eliminación señalan la reducción de la carga de mantenimiento (por qué mantener una plantilla completa cuando los enlaces están allí automáticamente) y esperan que la eliminación pueda presionar a MediaWikians para mejorar la interfaz móvil.

Existe un consenso general a favor de A2, por lo que la definición manual del nombre de la categoría Commons debe eliminarse o no agregarse, pero con la importante advertencia de que se deben utilizar anulaciones manuales cuando los enlaces automáticos no se ajusten a nuestras necesidades. Los editores que apoyan señalan el costo de mantenimiento reducido, ya que los enlaces no necesitarían cambiarse manualmente (o romperse) cuando Commons mueve una categoría Gran parte de la oposición a A2 proviene de un malentendido de buena fe, ya que los editores se oponen firmemente a perder el control editorial de nuestra prácticas de vinculación entre proyectos. Los editores estuvieron de acuerdo enérgicamente en ese punto, pero como se señaló, la propuesta no eliminaría la capacidad técnica de la plantilla ni prohibiría su uso cuando hacerlo sirve mejor a nuestros lectores.. Lo más importante es que esto no debe hacerse mediante programación (es decir, mediante un bot) y cualquier eliminación debe realizarla un humano con su mejor criterio.

Los editores están divididos en A3 (siempre definen enlaces) pero no hay consenso para definir siempre enlaces manualmente. En general, los partidarios de esta opción están argumentando en contra de una supuesta eliminación masiva y pérdida de control editorial, pero este parece ser un caso de c2: HeatedAgreement . Los editores que opten por eliminar los enlaces de bienes comunes definidos manualmente deben tener en cuenta estas preocupaciones y hacerlo de forma lenta y cautelosa (consulte WP: MEATBOT ) para que otros editores familiarizados con el tema tengan tiempo de revisar la decisión y plantear inquietudes sobre si un enlace es necesario.

Por razones en gran parte similares, existe un consenso aproximado contra la opción B, por lo que cualquier tarea de bot que agrega la plantilla a las categorías no tiene consenso (y nuevamente, consulte WP: MEATBOT para saber cómo esto afecta la edición de alta frecuencia o semiautomática)

- Wug · a · po · des 19:38 5 de marzo 2021 (UTC)

  • Enfréntate a A1 sin siquiera parpadear. Estoy seguro de que el 99,9% de los lectores no saben que la barra lateral está ahí, y en un tema con muchos enlaces entre idiomas, los lectores nunca lo verán. Me opongo débilmente a A2, ya que no veo ninguna ventaja en particular en eliminar la capacidad de anular la etiqueta mostrada. Si estas son las únicas tres alternativas, entonces es compatible con A3 , aunque podría aceptar A2 siempre que haya un medio para anularlo o deshabilitarlo en circunstancias en las que lo que hay en Wikidata no se considera apropiado. Definitivamente me opongo a B , ya que hay ocasiones en las que intencionalmente no vinculamos a Commons para un tema determinado. -  Iridiscente 20:18, 11 de diciembre de 2020 (UTC)
    @ Iridiscente : como se indica en la descripción de A2, "esto también permitiría anulaciones locales". Gracias. Mike Peel ( charla ) 09:17, 12 de diciembre de 2020 (UTC)
  • Oponerse a A1 y Apoyar A3 Tener siempre control local sobre el destino del enlace, lo hace más fácil para los usuarios. Keith D ( charla ) 20:30, 11 de diciembre de 2020 (UTC)
    @ Keith D : ¿Puede explicar cómo eso 'facilita las cosas a los usuarios', por favor? Gracias. Mike Peel ( charla ) 21:03, 11 de diciembre de 2020 (UTC)
  • Preocupación (no oposición) ... Aquí en WP.en nos hemos vuelto muy recelosos de vincular a Wikidata (en cualquier forma). Hay momentos en que los dos proyectos simplemente no parecen hablar el mismo idioma, y ​​eso ha causado dolores de cabeza a ambos proyectos. No tengo idea si esto es una excepción o no ... pero tenga cuidado. Blueboar ( charla ) 01:28, 12 de diciembre de 2020 (UTC)
  • Support A1 es el más fácil de mantener con las herramientas a nuestra disposición y con protecciones de sentido común contra el vandalismo. A1 es cuestión de acostumbrarse y saber dónde buscar. La plantilla puede tener un período de desactivación en el que dice "Consulte la barra lateral izquierda para ver el enlace a Commons" para ayudar a educar durante el período de transición. Si falla A1, también admitiría A2 w / Bot add (suspiro ... ¿ves cuánto mejor es A1?). Oponerse a A3. - Green C 02:38, 12 de diciembre de 2020 (UTC)
    Pregunta genuina y no ser estirado, pero ¿cómo crees que funcionaría "acostumbrarse"? En el aspecto en el que más del 50% de los lectores ven Wikipedia, A1 no solo cambiaría la ubicación del enlace, sino que lo eliminaría por completo.; desde la perspectiva de los lectores, esto no sería una cuestión de buscar en otro lado para navegar a Commons, sino de que Commons de repente aparentemente deja de existir. (Los lectores existentes probablemente sabrán preguntar dónde se ha ido, pero los nuevos lectores no tendrían ninguna razón para sospechar que los enlaces existieron). Además, Wikipedia no tiene solo una cohorte de lectores; gente nueva nos descubre todo el tiempo. La mayoría de las personas que ven una categoría han llegado allí mediante una búsqueda o mediante los enlaces de un artículo de Wikipedia y no son conocedores que entienden las peculiaridades de MediaWiki, y "los enlaces de las páginas de Wikipedia a contenido relacionado aparecen en esa página" es muyconvención bien establecida reforzada por 20 años de categorías y plantillas de navbox. No se puede esperar que un lector típico sepa que si está buscando los medios asociados con una categoría, debe cambiar a la vista de escritorio si aún no está allí, y luego, una vez allí, haga clic en un "In other projects: Wikimedia Commons"enlace críptico oculto en la barra lateral. -  Iridiscente 06:40, 12 de diciembre de 2020 (UTC)
    Ay, eso es un error bastante importante. No lo había notado desde que nunca utilizo la interfaz móvil. Eché un vistazo a Phabricator para ver si había un informe de error existente, pero no pude encontrar uno, así que comencé con phab: T269992 . Gracias. Mike Peel ( charla ) 09:17, 12 de diciembre de 2020 (UTC)
    Repito mi complemento para el gadget que se analiza aquí, que agrega un botón de un clic para obtener una vista previa de cómo se verán las páginas para los lectores (que usan principalmente la vista móvil) en lugar de los editores (que rara vez lo hacen). Se sorprenderá de la cantidad de cosas que da por sentado que faltan por completo o se comportan de manera completamente diferente (vea el desastre que el Usuario: Mike Peel mira en la vista móvil, como un ejemplo obvio). Si me saliera con la mía, rechazaríamos la vista móvil y volveríamos a empezar desde cero (creo que el aspecto actual es irremediablemente malo tanto para los lectores como para los editores), pero no puedo imaginarme a la WMF admitiendo alguna vez que han gastado un proyecto favorito una década de promoción es un limón completo. -  Iridiscente 13:22, 12 de diciembre de 2020 (UTC)
  • Soporte A1 . El enlace Commons es solo un ejemplo de los enlaces de "otros proyectos", y mostrarlos automáticamente como parte de la interfaz de usuario tiene más sentido que agregar una o más plantillas a cada categoría. Si la interfaz móvil no muestra estos enlaces, entonces debería corregirse. Quizás la eliminación de las plantillas existentes debería retrasarse hasta que se solucione. ghouston ( charla ) 02:18, 13 de diciembre de 2020 (UTC)
  • Oponerse a A1 , Oponerse a A2 , Apoyar a A3 Tener siempre control local sobre el destino del enlace, facilita a los usuarios. Como dijo Keith_D. O, como dije durante el último RFC: Oponerse . Kerry lo expresó bien. Durante mucho tiempo me han preocupado los esfuerzos persistentes para la eliminación masiva sistemática de contenido de Wikipedia, a favor de la oscura propiedad remota de todo por parte de la granja de robots conocida como Wikidata. Uno de estos días necesitamos llegar a un consenso comunitario sobre la práctica en general. O deberíamos transferir todo lo posible a Wikidata y aceptar que Wikidata se encargará de todo.de ahora en adelante, o necesitamos revertir Wikidata a categorías de seguimiento y propósitos raros de valor específico. Esta lucha interminable para hacer avanzar Wikidata hacia adelante (o hacia atrás) una pulgada a la vez es un desperdicio en el mejor de los casos y disruptiva en el peor. Alsee ( charla ) 16:26, 8 de mayo de 2019 (UTC) [1]Un pequeño número de entusiastas de Wikidata han estado tratando persistentemente de eliminar contenido en forma masiva arruinando a otros editores en una cruzada sagrada para hacer de Wikidata el señor y gobernante de todo lo que examinan. Entre otros problemas, el editor típico va a presionar CTRL-F tratando de encontrar el contenido que desea cambiar, y no estaría allí. Es posible que eventualmente encuentren la plantilla que podría ser completamente inútil en el wikitexto, pero no tendría ningún valor allí. El editor se queda varado con una edición imposible, absolutamente ninguna indicación de dónde está sucediendo WTF, y no hay camino a seguir. Alsee ( charla ) 16:31, 13 de diciembre de 2020 (UTC)
  • Apoyar A2 y B . El editor típico no necesita editar enlaces técnicos entre proyectos. Ruslik _ Zero 20:38, 13 de diciembre de 2020 (UTC)
  • Oponerse a A1 , Oponerse a A2 , Apoyar a A3señalando que tendríamos que desalentar explícitamente a los editores bien intencionados que eliminen las etiquetas "porque está en Wikidata", como ya ha sucedido con el ejemplo A3. A veces, la diferencia entre el nombre de la categoría Commons y el nombre local será discordante, más aún si esto se usa como un precedente para cambiar la forma en que se presentan los enlaces de las categorías Commons en los artículos: Commons tiene un enfoque más mundial en las categorías de titulación que cualquier Wikipedia individual tiene en las páginas de titulación y, como resultado, ha desarrollado diferentes convenciones, y aunque esto no surge mucho en las categorías ("en" versus "de" Líbano en el ejemplo A3 es apenas perceptible), será discordante en los casos en que sí importa. Con frecuencia he creado categorías en Commons con nombres diferentes a los de los artículos de Wikipedia,por ejemplo, usando un desambiguador en lugar de "The". Sobre el tema general, coincida conAlsee ; tener lo que el lector ve en una página determinado en Wikidata en lugar de en el proyecto individual es inaceptablemente arriesgado con respecto a vandalismo o error simple (corregí una descripción de Wikidata en holandés el otro día que asignaba algo al estado de EE. UU. equivocado) y hace que la edición inaceptablemente difícil; "Cualquiera puede editar" es uno de nuestros principios fundamentales, queremos que los lectores se sientan atraídos por corregir o actualizar algo y tengan la satisfacción de ver su cambio en vivo, y queremos que aquellos que agregan o expanden algo corrijan las cosas vinculadas a él ( WP : SOFIXIT). Wikidata está intencionalmente detrás de un muro de accesibilidad empinado porque es algo para los profesionales de la información y porque los errores allí potencialmente afectan a todos los proyectos. Así que debo oponerme a A2 y especialmente a A1 (el punto de Iridescent también es muy importante con respecto a A1, y estoy asombrado de que WMF no lo supiera). Dicho esto, no veo ningún daño en la ejecución del bot siempre que conservemos la capacidad de canalizar los enlaces cuando nuestra categoría se mueva a un nuevo título y ya no coincida con el de Wikidata: el soporte B siempre que se implemente A3 . Yngvadottir ( conversación ) 21:01, 13 de diciembre de 2020 (UTC)
  • Oponerse a A1 , Oponerse a A2 , Apoyar A3 El control local proporciona la flexibilidad necesaria. Otro aspecto es el idioma - mi impresión Commons tiende a hacer más uso de nombres de idiomas locales donde enWikipedia a menudo usa nombres traducidos al inglés - es más probable que los nombres de categorías necesiten control local. Los cambios que no sean A3 suponen una correspondencia 1 a 1 entre los artículos de Wikipedia y las categorías comunes; Wikipedia ha cambiado donde quería agregar más de un enlace de categoría común. PsamatheM ( charla ) 23:21, 13 de diciembre de 2020 (UTC)
  • Como nominador, en caso de que no fuera obvio, mi preferencia a largo plazo es A1 (pero ese error con el sitio móvil debe corregirse primero), en este momento preferiría A2 ya que minimiza la duplicación de datos, que es el problema fundamental aquí. . Si tiene varias copias de los mismos datos, debe corregir cada una de ellas por separado. Almacenar ese enlace en Wikidata, de la misma manera que almacenamos interwikis allí, es la opción más simple: entonces es el mismo conjunto de datos aquí, en Wikidata y en Commons (donde ese enlace se usa para mostrar el cuadro de información multilingüe). Entonces hay más ojos en los enlaces y más posibilidades de que alguien detecte enlaces defectuosos y los corrija. Digo esto como alguien que ha revisado y corregido miles de enlaces de commons incorrectos de enwp durante el último año.
Podría vivir con A3 si es necesario, pero significa continuar con el bot / sincronizar manualmente los cambios entre Commons / Wikidata / here, que es solo un esfuerzo duplicado. En lo que respecta al vandalismo, usar los enlaces de sitio / enlaces entre wikis es la forma más segura, ya que la categoría debe existir para estar vinculada (no se puede cambiar a ningún fragmento de texto aleatorio). Actualmente no hay categorías que se vinculen a múltiples categorías de Commons, y rara vez debería ser necesario hacerlo, pero A2 aún permitiría que eso sea posible si es necesario. Similar al texto local si es realmente necesario (pero los nombres de las categorías de Commons son en inglés por defecto). Una pequeña cantidad de enemigos de Wikidata tienden a usar la misma retórica cada vez que se menciona Wikidata, lo cual no es realmente útil (es como argumentar que todos los sitios web deberían volver a la representación estática en lugar de usar bases de datos: no se escala). Con B,Estoy feliz de cualquier manera: si no hacemos eso, no tengo que codificar el bot, pero tampoco obtenemos muchos más enlaces a Commons (y tenga en cuenta que estos históricamente han sido bot- agregado a las categorías de todos modos). Gracias.Mike Peel ( charla ) 18:05, 14 de diciembre de 2020 (UTC)
  • Soporte A2 . Esta es la mejor opción de ambos mundos. Elimina la necesidad de mantener dos sistemas diferentes para vincular una categoría WP a su categoría Commons equivalente, pero también permite flexibilidad y control en el manejo de casos especiales. -  Finnusertop ( charla ⋅ contribuciones ) 16:42, 15 de diciembre de 2020 (UTC)
  • Oponerse a A1 a menos que y hasta que la vista móvil sea fija (según el nominador). Apoye a A2 siempre que no se vea como un paso para no permitir la anulación local, que seguirá siendo necesaria por todas las razones que otros han explicado anteriormente. Peter coxhead ( charla ) 17:50, 15 de diciembre de 2020 (UTC)
  • Oponerse a A1 , la semana oponerse a A2 y apoyar A3 por las razones descritas por Iridescent. - Euryalus ( conversación ) 23:12, 15 de diciembre de 2020 (UTC)
  • Oponerse a A1, A2, B, - Apoyar a A3 por las razones mencionadas anteriormente. Solo en la muerte termina el deber ( conversación ) 15:36, 16 de diciembre de 2020 (UTC)
  • Oponerse a A1 y A2 (muy fuertemente), B, - Apoyar A3 según Iri y otros anteriores. El problema con A2 es que (según tengo entendido) todos los enlaces de la categoría actual se eliminarán y las "superposiciones locales" tendrían que volver a agregarse manualmente. "Matching Wikidata" es una prueba totalmente indigna de confianza. Sería una pesadilla. Johnbod ( charla ) 15:44, 16 de diciembre de 2020 (UTC)
    @ Johnbod : La comprobación es que los enlaces entre enwp + Wikidata + Commons estén todos sincronizados, no solo 'coincidir con Wikidata'. Si no está de acuerdo con el enlace, entonces en A2 tendría que arreglar el enlace (por ejemplo, agregando la anulación local, que luego verificaríamos y corregiremos en Wikidata / Commons, o mejor, corrigiéndolo en Wikidata para que luego se arregle en todas partes), o en A3, entonces tendría que arreglar el enlace (por ejemplo, cambiando la anulación local, que luego verificaríamos y corregiremos en Wikidata / Commons). De cualquier manera, el trabajo que tendrías que hacer es muy similar, difícilmente es una pesadilla. Recordatorio de que enwp / wikidata está actualmente sincronizado al 100% para las categorías de las que estamos hablando. Gracias. Mike Peel ( charla ) 20:44, 16 de diciembre de 2020 (UTC)
  • Semanalmente se oponen a A1 , apoyan firmemente a A2 y se oponen fuertemente a A3 como se explica a continuación
    • Semanal Oppose A1 de hecho, los enlaces a los otros proyectos de wikimedia son, desde mi punto de vista, no lo suficientemente visibles para los lectores de wikipedia como para llevarlos a hacer clic en este enlace en el menú lateral. Robby ( charla ) 21:50, 19 de diciembre de 2020 (UTC)
    • Apoyo firmemente a A2 desde mi punto de vista, esta es en este momento la mejor solución. Robby ( charla ) 21:53, 19 de diciembre de 2020 (UTC)
    • En realidad, oponerse firmemente a A3 resultará en un trabajo interminable por parte de los bots y la verificación manual de las categorías eliminadas respectivamente movidas en Commons. Robby ( charla ) 22:33, 19 de diciembre de 2020 (UTC)
  • En general, apoyo A1 , pero creo que es mejor dejar esa pregunta para un RFC más general en los recuadros que colocamos al final de los artículos. También apoyo A2 como resultado mínimo, ya que elimina la duplicación de lo que es solo otro enlace interwiki al final del día, que ya aceptamos administrando enlaces interwiki en Wikidata. Oponerse duro a A3 . También me opongo a B porque no quiero ver una expansión continua de estas cajas; en segundo lugar, hacer cumplir la inclusión por bot de estos parece anular la voluntad aparente de los editores en la edición de páginas particulares. - Izno ( charla ) 18:17, 20 de diciembre de 2020 (UTC)
  • Admite A2 para una mejor visibilidad de la conexión, pero A1 también está bien para mí. Deberíamos aprovechar Wikidata tanto como sea posible en escenarios no controvertidos como este. - MarioGom ( charla ) 14:16, 4 de enero de 2021 (UTC)
  • Oponerse A1, A2 Soporte, Neutro A3, B Asistencia técnica . Esto brinda la mejor combinación de visibilidad y evita la duplicación innecesaria de esfuerzos. Thryduulf ( conversación ) 16:05, 9 de enero de 2021 (UTC)
  • No me importa demasiado A1-A3 (aunque creo que la definición local es mejor, los objetivos de en.wikipedia y wikidata no siempre se alinean y las definiciones a veces son diferentes). Sin embargo me opongo fuertementecualquier adición automática o ciega de la 'categoría de bienes comunes' (y supongo que eso también es un acuerdo con el selectivo A1). Hay muchos casos en los que la categoría commons no tiene nada que se agregue a nuestros artículos (todas las imágenes ya están utilizadas y, aunque en casos raros, commons tiene menos de lo que tiene en.wikipedia), y enviando personas a commons para encontrar menos ( o lo mismo) que lo que está aquí es una tontería y solo obstruye nuestros artículos (especialmente cuando obtienes toda la serie de enlaces hermanos). Tenga en cuenta que los comunes a veces tienen diferentes recortes de 1 imagen, por lo que incluso si el número de imágenes en los comunes es mayor, todavía no se suman. - Dirk Beetstra T C 14:11, 10 de enero de 2021 (UTC)
  • A3 (y A2 cuando los nombres son iguales). Con demasiada frecuencia, las categorías comunes no tienen nombres que coincidan con los nuestros.  -  SMcCandlish ☏ ¢  😼  08:33, 15 de enero de 2021 (UTC)
  • Oponerse a A1 y A2. Y soporte A3 . Y es compatible con B, pero solo si dice "Enlace agregado por bot". Y Mike Peel , deje de eliminar los enlaces de categorías de bienes comunes que no coincidan exactamente con el nombre del artículo en inglés o con las categorías de artículo en inglés. Vea esta diferencia . No tienes esa autoridad que yo sepa. Es un ejemplo de por qué un bot no debería eliminar categorías de bienes comunes. Los seres humanos como tú tampoco deberían hacerlo. Me di cuenta de tus contribuciones que estás en una juerga de botal hacerlo. El hecho de que sea administrador no significa que tenga derecho a hacerlo. Muéstrame la pauta. Tengo decenas de miles de ediciones tanto en los comunes como en Wikipedia. Sé que muchos de estos intentos de sincronización no funcionarán debido a las muchas idiosincrasias del trabajo de Commons y el trabajo de Wikipedia. Prefiero un enfoque aditivo. Deje que el bot agregue enlaces de commons, pero no permita que un bot elimine los enlaces de commons. - Timeshifter ( conversación ) 04:18, 9 de febrero de 2021 (UTC)
    • He seguido este comentario en [2] . Para ser claros, los reclamos de autoridad y acceso de administrador son irrelevantes aquí. Gracias. Mike Peel ( charla ) 20:54, 10 de febrero de 2021 (UTC)
  • Oponerse a A1 / A3, fuerte apoyo B, ya que una gran parte de los lectores probablemente ni siquiera sepan qué es "Wikimedia Commons", y "medios relacionados con ..." es mucho más fácil de entender. - TheImaCow ( charla ) 06:26, 23 de febrero de 2021 (UTC)
  • Apoye a A2 y B , oponga a los demás. Definir localmente el enlace es una mala idea en el 99% de los casos, aunque la opción aún debería existir, y tener solo un enlace de barra lateral es una reducción en la visibilidad sin una buena razón. Elliot321 ( discusión | contribuciones ) 01:43, 28 de febrero de 2021 (UTC)
La discusión anterior 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.

Convierta todos los avisos de variantes en inglés en avisos de edición [ editar ]

Esta propuesta surge de una discusión en curso en el laboratorio de ideas sobre cómo reducir el desorden de los anuncios publicitarios excesivos en las páginas de discusión, un fenómeno que conduce a la ceguera de los anuncios, abrumando y confundiendo a los nuevos editores y reduciendo la visibilidad de los avisos más importantes.

Una idea que publiqué que parece haber ganado especial interés es que no es necesario que aparezcan avisos de variantes en inglés (por ejemplo, {{ British English }}) en la página de discusión, en lugar de solo como un aviso de edición que aparece en la ventana de edición. mientras uno está editando el artículo. La razón principal es que nadie está controlando la variedad de inglés que se usa en las páginas de discusión, por lo que el único lugar que se necesita es el aviso de edición. Por lo tanto, propongo aquí que convierta todos los avisos de variantes en inglés existentes en las páginas de discusión para editar avisos en la página correspondiente. Esto se haría a través de una tarea de bot y, una vez completado, Módulo: aviso de variante en inglésse configuraría para que produzca un aviso de error si se coloca en la página de discusión de un artículo. {{u | Sdkb }}  charla 14:34, 10 de enero de 2021 (UTC)

Encuesta (variedades inglesas) [ editar ]

  • Apoyo como nominador. Para abordar dos posibles preocupaciones: (1) En el raro caso de que haya una discusión en la página de discusión sobre el cambio de la variante, es fácil para el proponente proporcionar el contexto. No puedo pensar en ninguna otra situación en la que las personas en la página de discusión deban prestar atención a la variante. (2) La modificación de los avisos de edición actualmente requiere permisos avanzados; Tengo entendido que esto se debe a razones técnicas y no a un consenso editorial. Este es un problema que debería abordarse por sí solo en algún momento, pero no creo que sea un impedimento insuperable aquí, ya que la mayoría de las páginas desarrolladas lo suficiente como para ser etiquetadas con un aviso de variante son monitoreadas por editores capaces de modificarlo, y de lo contrario, se les pedirá que creen una solicitud de edición, lo cual es bastante sencillo.{{u |Sdkb }} charla14:34, 10 de enero de 2021 (UTC)
  • Soporte Esta es una buena idea y debe implementarse, siempre que eventualmente se resuelvan los problemas técnicos (¿nuevo permiso?). G en Q uest "scribble" 15:34, 10 de enero de 2021 (UTC)
  • Soporte Hay un beneficio doble, ya que mejora simultáneamente tanto la página de discusión (al reducir el desorden) como la pantalla de edición (al mostrar información relevante), una situación en la que todos ganan. - Paul ❬ talk ❭ 16:55, 10 de enero de 2021 (UTC)
  • Oponerse La propuesta parece a medias porque no aborda el uso de plantillas como {{ Use British English }}, que son las que veo con más frecuencia. Para las páginas de discusión, podríamos usar algo como un cuadro de información que contendría información clave sobre el artículo, como su tamaño y calificación de calidad. El dialecto encajaría mejor en tal resumen de las propiedades del artículo. Andrew 🐉 ( charla ) 17:26, 10 de enero de 2021 (UTC)
    En cuanto a las plantillas de "uso", esto no las afectaría de una forma u otra; seguirán estando disponibles para cuando sea deseable designar una variante, pero no hay suficiente edición errónea como para que sea necesario un aviso. Podríamos discutir más adelante con qué frecuencia tener algo visible o invisible, pero por ahora creo que obtener todos los avisos visibles en formato editnotice es el mejor primer paso.
    Con respecto a su idea para un cuadro de información hipotético de la página de discusión, sugiero proponerlo en la discusión más amplia del laboratorio de ideas. Podría apoyarlo si se implementa bien, pero está más allá del alcance del cambio más estrecho que estoy tratando de lograr aquí. {{u | Sdkb }}  charla 19:12, 10 de enero de 2021 (UTC)
  • Excelente idea. Sospecho que si hubieran existido avisos de edición cuando se iniciaron estas plantillas, este problema no habría surgido. Ϣere Spiel Checkers 18:50, 10 de enero de 2021 (UTC)
  • Si se implementa un gran apoyo , esto sería enorme para reducir el desorden de las páginas de discusión y, de hecho, hacer que los avisos de variedad en inglés sean efectivos. Como dije en el laboratorio de ideas, las personas que están ignorando o ignorando una variedad de inglés establecida no estarán en la página de discusión y lo verán allí. Como tal, estoy convencido de que la posición actual en la página de discusión es básicamente inútil. Aza24 ( conversación ) 21:03, 10 de enero de 2021 (UTC)
  • Apoyar esto parece una forma de hacer que la información sea más efectiva y reducir el desorden de las páginas de conversación al mismo tiempo. Thryduulf ( conversación ) 22:06, 10 de enero de 2021 (UTC)
  • Soporte, ya hacemos esto para algunos artículos canadienses ... como Plantilla: Editnotices / Page / Canada .... todavía no se ve en la vista móvil :-( - Moxy 🍁 01:06, 11 de enero de 2021 (UTC)
  • Apoya una gran idea. Un beneficio adicional es que reduce la propiedad de los artículos al evitar que los nuevos usuarios publiquen etiquetas engvar inútiles. Dado que solo los administradores, los editores de plantillas y los modificadores de página pueden agregarlos si les hacemos avisos de edición, también les da algo que hacer a los editores de plantillas y los modificadores de página. - Wug · a · po · des 02:54, 11 de Enero 2021 (UTC)
    • También me gusta la idea de eliminarlos por completo. - Wug · a · po · des 21:45 13 de enero 2021 (UTC)
    • Es posible que los editores de plantillas y los desplazadores de página no quieran hacer otra cosa. Parece bastante simple escribir un bot con los permisos necesarios para hacer esto. Chroma Nebula (charla) 23:20, 26 de enero de 2021 (UTC)
  • Soporte para todo este género de avisos (engvar, formatos de fecha, etc.), pero, quizás heréticamente, también apoyaría todos los avisos de limpieza de la parte superior de la página que se incluyen en los avisos de edición, para que las personas que solo quieran consultar un artículo de información no se preocupan por ellos. Beyond My Ken ( charla ) 03:17, 11 de enero de 2021 (UTC)
    Más allá de My Ken , por avisos de limpieza en la parte superior de la página, ¿se refiere a cosas como {{ NPOV }} o {{ Investigación original }}? Creo que esos avisos son bastante necesarios desde la perspectiva del lector, ya que los lectores merecen saber cuándo un artículo tiene problemas importantes para poder leerlo con la debida precaución y escepticismo (sí, la gente siempre debería estar haciendo eso , pero confían en nosotros lo suficiente como para de facto a menudo no lo hacen). Sin embargo, eso es más cierto para algunos avisos que para otros; Pude ver un caso para muchos de los de estilo amarillo como {{ Cleanup bare URLs}} para convertirlo para que se muestre solo a los editores. La pregunta en ese momento es si estamos desperdiciando la oportunidad de convertir a los lectores en editores ofreciéndoles una tarea fácil. Todo esto es tangencial a la discusión actual, así que quizás lo lleve a otra parte si desea desarrollarlo más, pero espero que mi comentario sea motivo de reflexión. {{u | Sdkb }}  charla 11:05, 11 de enero de 2021 (UTC)
    No, tiene razón, me refería a los de "estilo amarillo" que se refieren principalmente a los editores. Beyond My Ken ( charla ) 21:26, 11 de enero de 2021 (UTC)
    Yo diría que un buen número de los carteles amarillos son útiles para los lectores (por ejemplo, Plantilla: Sobrecolorado para que los usuarios daltónicos sepan que es posible que no interpreten algo en la página correctamente, o Plantilla: tipo ensayo ). Además, como he estado editando incluso los que los lectores que no son editores pueden no encontrar útiles, ahora informan cómo leo. Por ejemplo, ver Plantilla: Debateno habría cambiado la forma en que leí algo en el pasado, pero ahora me sugiere que las personas pueden tener un punto de vista bifurcado, puede que no haya un gran uso de revisiones / metanálisis (en el caso de artículos científicos) o su edición. puede haber sido una serie de adiciones inconexas. También son útiles para editar: me desviaré de hacer otras tareas para corregir un artículo si noto algún tipo de pancartas, incluso cuando no tenía la intención de editarlo. - Xurizuri ( charla ) 10:55, 12 de enero de 2021 (UTC)
  • Soporte Gran idea, este banner contribuye a la propagación y espero que esto reduzca los conflictos innecesarios, ya que muchas ediciones bien intencionadas de editores nuevos y de IP están relacionadas con ENGVAR. - Tom (LT) ( charla ) 03:20, 11 de enero de 2021 (UTC)
  • El soporte no es útil en las páginas de discusión, útil al editar lo que se muestra en editnotice. No es necesario un nuevo permiso, ni la edición de los avisos de edición debe estar disponible para todos, PMR y TPE pueden hacer esto. Si la cola de TPER se vuelve demasiado larga, podemos hacer que un bot con TPE transfiera las adiciones de la página de discusión al aviso de edición. ProcrastinationReader ( charla ) 09:21, 11 de enero de 2021 (UTC)
    Apoyar el uso de plantillas ocultas como {{ Use British English }} en la prosa del artículo, como dijo Whatamidoing, y eliminar todos los avisos de edición y los banners de la página de discusión y convertirlos en plantillas ocultas como {{ Use British English }} . Alternativamente, una plantilla de {{ estándares del artículo }}, como se describe en el hilo de Levivich. Los argumentos de Levivich y L235 son convincentes en mi opinión. ProcrastinationReader ( charla ) 15:15, 5 de febrero de 2021 (UTC)
  • Soporte por propuesta ~ ToBeFree ( charla ) 11:09, 11 de enero de 2021 (UTC)
  • Soporte : reducir la hinchazón de la plantilla de la página de discusión y ayudar a los nuevos editores a comprender Engvar al mismo tiempo me suena como una clara ventaja para todos. Enojado Arpía charla 12:47, 11 de Enero 2021 (UTC)
  • Creo que me opongo por razones de simpatía. 2 razones: 1) No creo que esto sea técnicamente factible. Solicita hacer un aviso de edición para esencialmente 6 millones de páginas. Esa es una gran cantidad de infraestructura. (Alguien me dice que estoy equivocado). 2) Creo que el remedio correcto es eliminarlos en su totalidad de las páginas de discusión. No es necesario que estén presentes tanto en su lugar canónico como en las etiquetas de los artículos y en las páginas de discusión. (Reemplácelo según sea necesario en el artículo correspondiente.) - Izno ( charla ) 14:41, 11 de enero de 2021 (UTC)
    • @ Izno : Creo que sería como máximo crear 41.000 avisos de edición con el uso actual del módulo eng var . - Paul ❬ talk ❭ 18:36, 11 de enero de 2021 (UTC)
      • Solo un 41k casual. Eyeroll. - Izno ( conversación ) 18:44, 11 de enero de 2021 (UTC)
        • Trivial para un bot. Thryduulf ( conversación ) 19:57, 11 de enero de 2021 (UTC)
        • Trivial o no, una cifra muy diferente a 6 mil. - Paul ❬ talk ❭ 21:14, 11 de enero de 2021 (UTC)
          • La creación es "trivial para un bot". ¿Mantenimiento y filtrado a través del ruido en el espacio de nombres de la plantilla buscando algo más que avisos de edición? Sí, no tanto. - Izno ( conversación ) 01:39, 12 de enero de 2021 (UTC)
  • Soporte Parece una buena idea que vale la pena seguir. - Jayron 32 18:16, 11 de enero de 2021 (UTC)
  • Soporte Reducir el desorden de las páginas de discusión es una buena idea. Remagoxer ( charla ) 20:51, 11 de enero de 2021 (UTC)
  • Apoyo. Sería más útil como un aviso de edición: sé que nunca reviso primero, y es un dolor tener que abrir la página de discusión en una nueva pestaña (especialmente porque tengo TDAH y, a veces, olvido la variante tan pronto como cierro dicho pestaña). Idealmente, también sería bueno tener avisos similares sobre el estilo de escritura en un artículo dado como avisos de edición. Sin embargo, una preocupación sería que al reducir el desorden de las páginas de discusión, no solo necesitamos reubicar el desorden (barrerlo debajo de la alfombra, por así decirlo). - Xurizuri ( charla ) 10:55, 12 de enero de 2021 (UTC)
  • Soporte, pero ¿qué pasa con las páginas protegidas? Podría haber un aumento de la solicitud de edición de ENVAR (incorrecta), supongo que también agregaría un mensaje en la página de discusión. (por favor haga ping) DarthFlappy 18:53, 12 de enero de 2021 (UTC)
    @ DarthFlappy : Esperaría que la gran mayoría de las solicitudes de edición provengan de personas que intentan editar una página protegida (que no cumplen con los requisitos), hacen clic en el botón para solicitar una edición y completan el formulario. Es posible que haya notado que muchos están en blanco; esto se debe a que la gente no lee lo que está en su pantalla y simplemente hace clic en el botón azul "Enviar" (tal vez pensando que están solicitando permiso para que se les otorgue acceso de edición). Pero de todos modos, no creo que el banner de la página de discusión realmente haga una diferencia en el contenido de la solicitud de edición. - Bilorv ( conversación ) 23:49, 14 de enero de 2021 (UTC)
  • Oponerse a Will solo empeorará la ceguera de los carteles. CaptainEek edita Ho Cap'n! ⚓ 20:41, 12 de enero de 2021 (UTC)
  • Soporte pero no a escala, y solo como piloto. Según tengo entendido, esto podría afectar a millones de artículos, así que pruébelo primero como prueba piloto de cientos de artículos. Los grandes cambios como este se realizan mejor con casos de prueba, paso del tiempo, múltiples solicitudes de comentarios y documentación. Esto ya cuenta con mi apoyo general y también anticipo volver a apoyar en el futuro, pero la propuesta tal como está no tiene límites. La escala y el ritmo de los cambios me importan. Solo espero documentación a nivel de voluntario y no la mejor y más completa, y animo al piloto. Reconozco la existencia del problema y siento que solo crecerá. Hay varias soluciones posibles, y quizás tengamos que usar varias soluciones a la vez para abordar este problema. Primero desarrolle esta solución. Frambuesa azul(charla) 20:51, 12 de enero de 2021 (UTC)
  • Oponerse a los banners de editnotice son mucho más molestos que los avisos de las páginas de discusión. Ralentizan la edición. Graeme Bartlett ( charla ) 22:18, 12 de enero de 2021 (UTC)
  • Oponerse - Enwiki tiene que ser la única publicación en el mundo que escribe una sola obra usando múltiples variedades de inglés. Engvar no es lo suficientemente importante como para tener banners de páginas de discusión, estoy de acuerdo, pero la solución es eliminarlos por completo. Moverlos al aviso de edición creará ceguera de aviso de edición en lugar de ceguera de banner de página de discusión, y eso es aún peor, porque en teoría, los avisos de edición tienen cosas realmente importantes, incluso más que los encabezados de página de discusión. La creación de miles o millones de avisos de edición supone un gran aumento de gastos generales y de mantenimiento. Los avisos de edición son molestos y, de todos modos, se ignoran en gran medida. No se muestran en absoluto para los usuarios de dispositivos móviles. En general, creo que esto lleva el problema a un lugar peor en lugar de aliviarlo. Levivich  acosar /sabueso 04:53, 13 de enero de 2021 (UTC)
    Este es un buen punto. Estaba pensando que el aviso debería recortarse, literalmente en una viñeta como: "* Este artículo usa inglés británico". Alternativamente, podemos tener una sola plantilla de página de discusión de "Convenciones de artículos" que está muy recortada y significa estándares como la variedad de inglés utilizado; esto supone que hay otros tipos de estándares además del inglés y la variedad de fechas que posiblemente podrían aplicarse. Un poco como . ProcrastinationReader ( charla ) 09:16, 13 de enero de 2021 (UTC){{article standards|lang=British|dates=dmy}}
    Una plantilla de convenciones de artículos parece una muy buena idea. Probablemente hay otros además de engvar y usedmy, pero esos dos son buenos ejemplos. Me parece que la iconografía es la forma más eficiente de comunicar este tipo de cosas, pero no estoy seguro de que todos estén de acuerdo con eso. Así que como una pequeña bandera británica en algún lugar si se usara BrEng, una bandera estadounidense para AmEng, algo así. Levivich  acoso / sabueso 17:27, 13 de enero de 2021 (UTC)
    Estoy de acuerdo en que los avisos deben mantenerse discretos y concisos. Con respecto al punto "simplemente elimínelos por completo", ya tenemos la familia de plantillas, por ejemplo, {{ Use British English }}, que establece el estándar sin mostrar nada, tal como lo describe. Estoy indeciso acerca de cuándo deberíamos usarlo en comparación con el {{ inglés británico }}, pero creo que, en circunstancias en las que es lo suficientemente importante como para justificar un banner, ese banner debe estar próximo al lugar donde realmente se aplica, lo que significa ponerlo en el aviso de edición junto al artículo en lugar de en los carteles de la charla junto a la charla. {{u | Sdkb }}  charla 00:06, 14 de enero de 2021 (UTC)
  • Oponerse Deberíamos guardar los banners para las cosas verdaderamente importantes como BLP, en lugar de para la ortografía. ( t · c ) buidhe 18:35, 13 de enero de 2021 (UTC)
  • Opónganse por Graeme Bartlett y CaptainEek. ~ HAL 333 22:19, 13 de enero de 2021 (UTC)
  • Soporte : parece una obviedad. La ceguera del banner en una página de discusión ya es un problema masivo, y ENGVAR no es relevante para leer la página de discusión, es relevante para editar la página, por lo que debería estar donde sea relevante. Sceptre ( charla ) 23:33, 14 de enero de 2021 (UTC)
  • Oponerse : es una propuesta absolutamente razonable, pero preferiría eliminar estos banners de la página de discusión. Simplemente no creo que la variante del idioma sea lo suficientemente importante como para merecer este tipo de atención, sino que solo causará ceguera en el lector donde sea que aparezca. Entiendo que es muy frustrante revertir los mismos cambios ortográficos de buena fe una y otra vez (he perdido la cuenta de la cantidad de veces que he tenido que revertir "plazo" a "plazo" en BritEng Black Mirror serie de artículos), pero he descubierto que la mayoría de los editores no registrados no verán un aviso de edición, una plantilla de wikicode oun comentario oculto en medio de una palabra que se cambia constantemente (no sé por qué el último no funciona, pero no lo hace), o posiblemente simplemente ignorarlos todos intencionalmente. Así que creo que esta propuesta, aunque parece la posición lógica de sentido común a la que mover la plantilla, solo crearía ceguera y tendría poco o ningún efecto para evitar redundancias de edición. - Bilorv ( conversación ) 23:40, 14 de enero de 2021 (UTC)
    @ Bilorv : Tu comentario acerca de tener que corregir la misma palabra una y otra vez me hace pensar: ¿qué pasaría si tuviéramos un filtro de edición para que, por ejemplo, cualquiera que intente introducir "entrega" en un artículo etiquetado con inglés británico reciba una advertencia importante? cuando intentan publicar? {{u | Sdkb }}  charla 01:58, 15 de enero de 2021 (UTC)
    Creo que no es razonable que los usuarios nuevos / IP no tengan forma de conocer esta información antes de editarla. Sí, lo más probable es que no lean el aviso, pero "hay un aviso que ignoraste" es mucho mejor que "hay una política oculta en nuestro espacio de nombres WP arcano (para nuevos usuarios) que ni siquiera conoces". Y dado que las variedades de inglés son en gran parte idénticas, a veces es difícil saber en qué variante está el artículo; el aviso es un buen recordatorio. -Novov T C 07:57, 15 de enero de 2021 (UTC)
    Para Sdkb , eso es posiblemente algo que podría admitir, pero realmente no me gustan los filtros de edición dirigidos a los novatos porque es una barrera más para la entrada. Si hubiera una manera de decir "literalmente, los únicos cambios en esta edición son cambios de ortografía incorrecta", entonces sería ideal. Sé que es pedir mucho. Para Mir Novov , muchas ediciones de buena fe que veo por parte de nuevos usuarios / IP que tengo que revertir son algo que no podía esperar razonablemente que entendieran. ¿Ha habido una discusión en la página de discusión? El prospecto no menciona esto debido al peso debido? ¿Esta fuente no es confiable a pesar de que es un periódico que un millón de personas leen al día? ¿Está mal llamar a una sección "Controversia" a pesar de que ha visto otros 1000 artículos con ese mal título? En todo caso, me parece que "este artículo usa inglés australiano porque se trata de un programa australiano" es mucho más fácil de explicar que la mayoría de los errores habituales. - Bilorv ( conversación ) 09:37, 15 de enero de 2021 (UTC)
    Bilorv , en mi versión idealizada de Wikipedia 2030, la forma en que ese filtro funcionaría es que alguien entrara e intentara hacer un mal cambio a otra variante dentro de una edición que de otro modo sería buena, y cuando hacen clic en publicar, aparece un aviso que dice "Oye, cambiaste 'installment' a 'installment', que parece ir en contra del inglés británico utilizado para este artículo. ¿Te gustaría (a) publicar, pero mantener el inglés británico? [Funciona con un clic], o (b ) publicar de todos modos? "
    Sin embargo, incluso con eso, estoy de acuerdo con Novov en que, para las páginas donde los interruptores son comunes (que es el grupo que estamos discutiendo aquí), es mejor no hacer que alguien haga todo el trabajo antes de darles la alerta. Y no son solo los recién llegados, no sabía que "entrega" era una de las palabras que diferían hasta que lo mencionaste anteriormente, por lo que fácilmente podía verme cometiendo ese error. Mientras que si hay un aviso de edición que (de nuevo, pensando futurísticamente) detecta automáticamente que "instalación" se usa mucho en esa página y, por lo tanto, lo incluye en los ejemplos, eso me permitirá saber que no debo tocar nada. {{u | Sdkb }}  charla 13:05, 15 de enero de 2021 (UTC)
  • Soporte : esta información es más útil para editar páginas, no discusiones. Lógicamente, debería pertenecer allí, y tal reubicación sería útil para los editores de IP que han "corregido" la ortografía. Sí, hay otra información en la página de discusión que debería leerse, pero mucha gente no lee eso, y las ilusiones no harán que ese hecho desaparezca. -Novov T C 07:57, 15 de enero de 2021 (UTC)
  • Oponerse . La instrucción es lenta , demasiado intrusiva y solo conducirá a más ceguera de aviso de edición. Charla de neutralidad 19:43, 15 de enero de 2021 (UTC)
  • Oponerse a la neutralidad. Personalmente, no me gustan los avisos de edición y más avisos de edición que se inmiscuyan en la interfaz de edición es algo que no me gustaría. Quizás algo similar a la Plantilla: usar la plantilla de fechas mdy sería mejor. Una gran cantidad de avisos de edición sobre las variedades nacionales del inglés (a veces donde los avisos de edición ya están en su lugar) sería peor que la ceguera del banner de la página de discusión para los creadores de contenido, pero tendrían que desplazarse más allá del aviso de edición cada vez que editan. Además, las variedades nacionales del inglés realmente no son tan importantes y, como tal, es por eso que debemos mantenerlas en las páginas de discusión. P, TO 19104 ( charla ) ( contribuciones ) 23:08, 15 de enero de 2021 (UTC)
  • Opónganse por Graeme Bartlett y CaptainEek. Cavalryman ( hablar ) 03:14, 16 de enero de 2021 (UTC).
  • Oponerse . Las variedades de inglés no son lo suficientemente importantes como para justificar su ubicación como un aviso de edición. Intente y observe qué variedad está usando el artículo y emule eso; si se equivoca, alguien le ayudará a solucionarlo. En mi opinión, el banner de la página de discusión existe solo para intentar evitar las guerras de edición sobre este tema, y ​​un lado puede apuntar al banner. El resto del tiempo no es útil, ya sea en la página de discusión o como un aviso de edición. KevinL ( también conocido como L235 · t · c ) 20:07, 18 de enero de 2021 (UTC)
    • Además de esto, hay algunos avisos de edición verdaderamente importantes (por ejemplo, avisos de DS que crean delitos bloqueables), y cuantos más avisos de edición agreguemos, más ceguera de banner obtenemos. Los avisos de la página de discusión ya se ignoran; no consigamos los avisos de edición a la misma suerte. KevinL ( también conocido como L235 · t · c ) 20:09, 18 de enero de 2021 (UTC)
    Si bien veo su argumento, para ser justos, el formato de aviso de edición ya existe en este momento y se coloca arbitrariamente; admins / TE / PMRs lo colocarán ellos mismos o a pedido de otros editores, también en línea con la documentación actual para estas plantillas. Las páginas que solo tienen un aviso de conversación suelen ser arbitrarias. ProcrastinationReader ( charla ) 20:12, 18 de enero de 2021 (UTC)
    • ¿Ya hay un aviso de edición? Eso es horrible. Vamos a borrarlo. KevinL ( también conocido como L235 · t · c ) 20:22, 18 de enero de 2021 (UTC)
      • Sí, consulte el documento de {{ inglés británico }}. Se hace usando un parámetro, pero la idea es (creo) usar ambos. Para aclarar, mi punto no es que debamos consagrar un patrón que puede no tener sentido, pero si no queremos avisos de edición de lenguaje, deberíamos eliminarlos por completo en lugar del sistema arbitrario actual.
        Personalmente, creo que lo reduzco literalmente a una viñeta, no a un aviso considerable, o cree un {{ estándares de artículos }} para las páginas de discusión. Por supuesto, cada opción tiene un propósito diferente: la primera está destinada a alertar a los editores que escriben para adaptar su idioma, la segunda para ayudar a los correctores a corregir errores. Personalmente, no conozco otras variedades de inglés, así que cometo mis 'errores' y dejo que alguien más corrija sus correcciones si les importa, por lo que posiblemente este último sea más inteligente. ProcrastinationReader ( charla ) 20:26, 18 de enero de 2021 (UTC)
        • El aviso de edición actual debe terminarse con perjuicio. KevinL ( también conocido como L235 · t · c ) 20:52, 18 de enero de 2021 (UTC)
          • Creo que he usado ese aviso de edición. Pero la idea es insertar el aviso solo si realmente necesita ser notado, es decir, hay un problema crónico con numerosas ediciones en la página. Entonces, en general, no debería agregarse en mi opinión. Graeme Bartlett ( charla ) 23:59, 18 de enero de 2021 (UTC)
  • Oponerse : los avisos de edición deben reservarse para instrucciones importantes específicas de artículos y páginas, y deben usarse lo menos posible. Abrir avisos de edición a avisos generales sobre estilos de artículos generará desorden y disminuirá significativamente la utilidad de los avisos de edición para esos avisos específicos de artículos y páginas. Vea también esta discusión de hace un par de años sobre esto exactamente que llevó al consenso de que los avisos de estilo no deben usarse de esta manera sin evidencia de interrupción. En la misma discusión, varios usuarios más inteligentes que yo también sugirieron que hacer esto contaminaría la base de datos con algunos cientos de miles de páginas nuevas y aumentaría el tiempo de carga de los artículos, sin ninguna razón particularmente importante. Ardilla de Ivanvector ( árboles/ nuts ) 01:04, 20 de enero de 2021 (UTC)
    Además, todavía no hemos resuelto el problema de que los avisos de edición no son visibles para los editores móviles, por lo que, de todos modos, no se adaptan bien a los avisos editoriales. Ardilla de Ivanvector ( árboles / nueces ) 01:06, 20 de enero de 2021 (UTC)
  • Oponerse, ya que esta propuesta parece ignorar el hecho de que los avisos de edición no se muestran en dispositivos móviles. SK2242 ( conversación ) 06:41, 20 de enero de 2021 (UTC)
    Tampoco hablan los avisos. O bien, están bien escondidos. ProcrastinationReader ( charla ) 23:00, 21 de enero de 2021 (UTC)
  • Débil se oponen ; ¿Cuántas veces ha leído en AN o ANI un recordatorio como, "Estimado OP, se perdió el aviso violentamente naranja cuando publicó aquí?" Si se pierden eso, ¿realmente creemos que un aviso de edición evitará que los observadores de la página tengan que volver a la EngVar correcta? Personalmente, creo que los avisos de edición deben guardarse para las cosas más importantes ~ cosas que si cruzas o fallas podrían terminar con tus privilegios restringidos. días felices, Lindsay H ello 14:10, 22 de enero de 2021 (UTC)
  • Admite, pero solo si hay una opción para que los editores que hayan iniciado sesión desactiven las notificaciones. Lugnuts Fire Walk with Me 17:23, 22 de enero de 2021 (UTC)
  • Oponerse a tener más avisos de edición . En el editor visual y el editor de wikitexto de 2017, debe hacer clic para pasar los avisos de edición cada vez que abre esa página para editar. Además, tal como dice la ardilla de Ivanvector , dejas de leerlos cuando son comunes. WT: MED tiene un aviso de edición en el que hice clic en la mayoría de los días durante los últimos años y ya no sé lo que dice. Cuando necesitemos tener notas sobre la variante de idioma a utilizar, conviértalas en plantillas "invisibles" que incluyan la información necesaria en el título, como {{ Use British English }}. WhatamIdoing ( charla ) 19:58, 22 de enero de 2021 (UTC)
  • Apoyo. Como han dicho muchos otros, muy pocos editores notarán los banners de las páginas de discusión, especialmente los IP y los novatos. Y la falta de atención a las instrucciones de ENGVAR a menudo ha llevado a guerras de edición disruptivas e inútiles. Por supuesto, debemos ser conscientes de no acumular tantos avisos de edición que la gente deje de prestar atención, pero esa es una discusión separada sobre cómo condensar los avisos de edición. Chroma Nebula (charla) 23:20, 26 de enero de 2021 (UTC)
  • Soporte : Incluso si la gente ignora el aviso, no será peor de lo que es ahora. Esta es una excelente manera de evitar que las personas cambien innecesariamente de una variedad de inglés a otra. Y, también, dado que más personas están viendo el hecho de que "¿se pueden etiquetar artículos por tipos de inglés?", Habrá más personas etiquetando, lo que, a su vez, conduce a una mayor estandarización y organización. Opal | zukor ( discutir ) 22:10, 29 de enero de 2021 (UTC)
  • Soporte , idealmente con el aviso reducido a lo esencial. Quizás solo este artículo está escrito en inglés americano , y esto no debería cambiarse sin consenso. Obtenga más información . Veo el uso de editnotices como una mejora en múltiples formas. Las páginas de conversación se vuelven menos abarrotadas. Es más probable que los novatos que no conocen nuestro enfoque de las variedades inglesas lo aprendan y eviten hacer cambios no deseados. Y los usuarios más experimentados que editan artículos sin fuertes lazos nacionales pueden ver rápidamente cómo deben escribir sin tener que revisar la página de discusión o escanear el artículo en busca de pistas sobre la variedad preferida. el wub "?!" 23:35, 30 de enero de 2021 (UTC)
  • Soporte : parece una buena idea. Rollo August ( charla ) 17:32, 3 de febrero de 2021 (UTC)
  • Oponerse según Levivich y L235. AVS malnad 77 talk 04:04, 5 de febrero de 2021 (UTC)
  • Oponerse . Los avisos de edición dificultan la edición. Deben reservarse para asuntos importantes. Espresso Addict ( charla ) 07:54, 11 de febrero de 2021 (UTC)
  • Enérgicamente en contra: En su lugar, elimine las versiones editnotice. No necesitamos intimidar a los editores, especialmente a los nuevos, sobre trivia de estilo cada vez que editan la página . Si alguien se equivoca, algún gnomo lo arreglará más tarde, como ocurre con todas las demás objeciones de estilo. MoS es una guía, no una política, por una razón. No se requiere que ningún editor lo siga al agregar contenido nuevo; no se les permite cambiar de manera disruptiva y obstinada el material para que no cumpla con las normas después de que se les haya pedido que dejen de hacerlo. Tratar de hacer que el seguimiento de un artículo de línea de MoS sea obligatorio para editar la página en absoluto es una ejecución final en torno a la política de WP: EDITING , es WP: BITEy , es WP: CREEPdel orden más alto, y también es un final de casi dos décadas de consenso de que ningún estilo importa, aparte de algunos puntos clave sobre el aumento de la titulación de artículos al nivel de política. Ya que estamos en eso, también elimine los banners de la página de discusión para esto. Las plantillas "silenciosas" como en la parte superior del artículo real son completamente suficientes.  -  SMcCandlish ☏ ¢  😼  18:01, 13 de febrero de 2021 (UTC){{Use British English}}
  • Soporte débil , esta es una opción para reducir el desorden actual. Estas plantillas ya existen como avisos de edición, por lo que si deberían o no deben ser una discusión diferente. De cualquier manera , como etiqueta de página de conversación o aviso de edición, deben reducirse drásticamente en prominencia / espacio de acuerdo con comentarios similares anteriores, en primer lugar eliminando banderas / otras imágenes según el espíritu de WP: FLAGCRUFT . Francamente, estos avisos se pueden reducir a dos palabras (por ejemplo, "inglés británico", "inglés americano") que se dejan en algún lugar coherente en la página de conversación / aviso de edición. CMD ( charla ) 17:46, 14 de febrero de 2021 (UTC)
  • Oponerse según SMcCandlish. Los avisos de edición deben reservarse solo para instrucciones / información importante. - NSH001 ( conversación ) 10:04, 20 de febrero de 2021 (UTC)
  • Oponerse al desorden del espacio de los avisos de edición con cientos de miles de avisos de edición sin sentido, mientras se asegura de que los avisos de edición deben ser aún más llamativos para que los usuarios los lean. Idealmente, tendríamos una ubicación estandarizada en el editor que muestra la variedad en inglés, y los avisos de edición son una forma engañosa y mala de emular esto de alguna manera. Elliot321 ( discusión | contribuciones ) 01:45, 28 de febrero de 2021 (UTC)
    Elliot321 , una ubicación estandarizada en el editor es un pensamiento interesante. ¿A dónde imagina que va? ¿Hay algún ticket de phab que vea si el WMF podría considerar agregar algo? {{u | Sdkb }}  charla 07:08, 3 de marzo de 2021 (UTC)
    Sdkb seguro, aquí hay una maqueta que hice para el editor de fuentes (lo que uso): Archivo: maqueta de variedad en inglés - source.png . No estoy seguro de si hay entradas fab. Elliot321 ( discusión | contribuciones ) 07:21, 3 de marzo de 2021 (UTC)
    Elliot321 , ¡me parece bastante bien! Si coloca el cursor sobre la palabra "británico", tal vez podría proporcionar una información sobre herramientas con ejemplos de palabras (idealmente adaptados a las palabras reales utilizadas en la página). Si avanza y convierte la maqueta en una propuesta más formal, lo apoyaría. Mi lectura de esta discusión es que definitivamente hay un deseo de hacer que la etiqueta de idioma sea menos prominente, pero solo hay desacuerdo sobre cómo hacerlo, por lo que creo que su solución podría tener un fuerte apoyo si se puede implementar. {{u | Sdkb }}  charla 07:39, 3 de marzo de 2021 (UTC)
    Sdkb sí, esa sería mi idea.
    Ahora, la pregunta es ¿cómo configurarlo? Aunque supongo que las plantillas {{ Use blah English }} lo hacen bien, y eso probablemente podría detectarse en el editor. Elliot321 ( discusión | contribuciones ) 07:43, 3 de marzo de 2021 (UTC)
  • Soporte La mayoría de los usuarios no se molestan en mirar la página de discusión a menos que quieran publicar una discusión allí. ¡Es posible que un nuevo usuario ni siquiera sepa que las páginas de discusión están ahí! Ésta es una propuesta muy útil. 🐔 ¡  Chicdat   Bawk para mí! 11:22, 5 de marzo de 2021 (UTC)
  • Oponerse . Apoyo la eliminación agresiva del desorden de las páginas de discusión, pero este aviso a un aviso de edición aún más visible no refleja con precisión su importancia (es un problema de MoS, y estoy de acuerdo con SMcCandlish en que no debemos aporrear a los editores al respecto, como un aviso de edición haría). - Goszei ( conversación ) 16:37, 8 de marzo de 2021 (UTC)
  • Durante mucho tiempo pensé que el aviso de variante debería ir en la página del artículo y no en la página de discusión. Bastaría con una simple nota de una línea que diga algo como "Este artículo utiliza la ortografía y la gramática del Reino Unido" en la parte superior de la página. Blueboar ( charla ) 16:50, 8 de marzo de 2021 (UTC)

Discusión [ editar ]

  • Si esto se adopta, ¿cómo se implementaría en relación con los avisos de edición existentes que ya incorporan la variedad en inglés? Es decir, consulte Wikipedia: artículos destacados / plantillas de Editnotice para obtener una lista de todos los avisos de edición de artículos médicos destacados, que ya incluyen variedad en inglés, incorporando una lista personalizada de palabras del artículo. (No soy un experto en tecnología, por favor deletree esto en detalle del Dummy 101). Sandy Georgia ( Discusión ) 16:46, 10 de enero de 2021 (UTC)
    • En los casos en los que ya está en el aviso de edición, creo que lo dejaríamos allí y solo lo eliminaríamos de la página de discusión. - Paul ❬ talk ❭ 17:07, 10 de enero de 2021 (UTC)
      Sí, para páginas como Template: Editnotices / Page / Rotavirus , ya se incluye , por lo que el bot simplemente eliminaría el aviso de la página de discusión y no agregaría un duplicado. Para la página poco común que tiene un aviso de edición de idioma personalizado, como Plantilla: Editnotices / Página / pandemia COVID-19 , eso sería un poco más complicado, pero aún factible; el bot podría simplemente omitir agregar cualquier cosa para los avisos de edición que enlazan a una página en Categoría: dialectos del inglés . {{u | Sdkb }} charla 19:55, 10 de enero de 2021 (UTC){{British English|form=editnotice}} 
  • Cambiar los banners de hablar al aviso de edición ayuda a hablar, pero hace que sea aún más improbable que la gente lea el aviso de edición. Me gustaría ver un borrador de cómo se implementaría exactamente esta propuesta (¿crear un millón de nuevos avisos de edición? ¿Crear un aviso de edición central con código mágico para mostrar la variedad de idiomas?), Y exactamente cómo aparecería. Intente editar Donald Trump para ver cómo se ve un aviso de edición. Johnuniq ( charla ) 22:59, 10 de enero de 2021 (UTC)
    • Su énfasis en lo grande que será el cambio es ciertamente válido, aunque no sé si estoy de acuerdo en que pasar a un aviso de edición hace que sea aún más improbable que la gente lea el aviso de edición , incluso solo la bandera de el Reino Unido o los EE. UU. en el aviso de edición harían más que ahora. La única alternativa que puedo ver a la situación actual o la solución propuesta anteriormente es eliminar por completo la variedad inglesa, que es un escenario más o menos imposible. Aza24 ( charla ) 00:10, 11 de enero de 2021 (UTC)
    • ¿Hacemos más pequeño el formulario de aviso de edición? ProcrastinationReader ( charla ) 09:25, 11 de enero de 2021 (UTC)
      • No estoy seguro de cuán factible es esto en un sentido técnico, pero si una plantilla de aviso de edición se trata del formato (por ejemplo, el orden de la fecha), la variante de idioma, etc., ¿podrían ser más pequeños y estar todos juntos justo encima del editor? Lo haría menos molesto, al mismo tiempo que sería fácil ubicar todas las pequeñas piezas relevantes de información sobre las convenciones de escritura. Alternativamente, estos podrían estar en una barra expandible, como lo están algunas de las listas de categorías al final de los artículos. - Xurizuri ( charla ) 10:22, 12 de enero de 2021 (UTC)
    @ Johnuniq , creo que esto implicará la creación de decenas de miles de avisos de edición. WhatamIdoing ( charla ) 20:01, 22 de enero de 2021 (UTC)
  • Muchos editores antiguos, la mayoría de los editores más nuevos y prácticamente todos los IP nunca se acostumbran a mirar la página de discusión antes de editar la página de un artículo. Los avisos de la versión en inglés en la página de discusión son inútiles. G en Q uest "scribble" 23:30, 10 de enero de 2021 (UTC)
    • Totalmente de acuerdo, y creo que esta propuesta debería abordar eso de manera apropiada. La ubicación actual de las plantillas de variedades en inglés es prácticamente invisible para el público objetivo. Aza24 ( charla ) 00:10, 11 de enero de 2021 (UTC)
      • Como editor más nuevo, nunca lo he verificado intencionalmente antes de editar, por lo que es al menos alguna evidencia anecdótica para su punto. Sin embargo, no estoy seguro de si esto es una función del aviso en la página de discusión, pero en el editor visual de algunos artículos hay un pequeño mensaje justo debajo del título (por ejemplo, Educación en Australia ). Soy un gran admirador de esos pequeños mensajes. - Xurizuri ( charla ) 10:22, 12 de enero de 2021 (UTC)
  • La necesidad de que intervenga un administrador obligará a un editor no administrador que advierta un cambio en la variedad en inglés que claramente se justifica a pasar dos sesiones de edición en la página. La primera sesión sería realizar una solicitud de edición protegida. El segundo sería cambiar realmente la variedad. Jc3s5h ( conversación ) 01:02, 11 de enero de 2021 (UTC)
    • Dada la poca frecuencia con la que se debe cambiar la variedad de inglés de una página, esto suena como un beneficio para esta propuesta: garantizar que solo suceda cuando haya una buena razón para hacerlo. Thryduulf ( conversación ) 11:12, 11 de enero de 2021 (UTC)
      • Estoy de acuerdo con esto. Requerir dos ediciones no es irrazonable para algo que define cómo está escrito todo el artículo. - Xurizuri ( charla ) 10:22, 12 de enero de 2021 (UTC)
  • Espero que los opositores sobre la base de "no deberíamos tenerlos en primer lugar" realmente hagan algo al respecto y propongan que los eliminemos todos juntos (si esta propuesta no fuera aprobada). De lo contrario, perderá el tiempo de todos. Aza24 ( conversación ) 06:08, 13 de enero de 2021 (UTC)
    Oponerse a un cambio de la segunda mejor solución (banners de página de discusión) a la tercera mejor solución (editar avisos) no es una pérdida de tiempo, incluso si uno no propone la mejor solución (sin banners). Hacer una propuesta que no tiene una probabilidad razonable de éxito es una pérdida de tiempo. A menudo, "segundo mejor" es el status quo porque es el compromiso. Levivich  acoso / sabueso 06:16, 13 de enero de 2021 (UTC)
    Se equivoca si cree que esta discusión no puede generar el consenso para eliminarlos de las páginas de discusión sin reemplazarlos. Las RFC no son votos.
    En segundo lugar, no estamos perdiendo el tiempo independientemente. Deberíamos preferir la mejor solución, como sea que lo hagamos. Es una falacia lógica argumentar que también debemos hacer cosas consistentes con nuestra posición, especialmente porque se trata de una misión voluntaria. (No tengo ningún problema en que me llamen hipócrita si quieres. :)
    En tercer lugar, esto es quizás lo menos preocupante en la wiki de hoy. No necesitamos el polarismo de tu parte. - Izno ( charla ) 22:09, 13 de enero de 2021 (UTC)
    Izno , literalmente en ningún lugar dije que nada como esta discusión no puede generar el consenso para eliminarlos de las páginas de discusión sin reemplazo , y ciertamente no estaba tratando de generar "polarismo" intencionalmente; las tergiversaciones no son apreciadas. Creo que fui bastante claro sobre lo que sería "perder el tiempo": una situación en la que las personas que se oponen sobre la base de "no deberíamos tenerlos en primer lugar", la propuesta falla, pero estos opositores no inician propuesta para eliminar los carteles de variedades inglesas. Porque en una situación en la que se plantea un problema que, en consecuencia, no se resuelve con la introducción de un problema mayor y ninguno termina siendo abordado es una pérdida de tiempo. Aza24 ( hablar) 22:39, 13 de enero de 2021 (UTC)
  • Obviamente, la mejor solución sería un bot que corrigiera automáticamente (y en silencio) la ortografía y el uso de cualquier variante designada (suponiendo que se haya designado una variante) ... con un resumen de edición que explique lo que se hizo y por qué. Entonces, los editores podrían simplemente escribir y no preocuparse por si estaban escribiendo en la variante designada. Blueboar ( charla ) 14:00, 15 de enero de 2021 (UTC)
    @ Blueboar : los editores que están escribiendo contenido nuevo no deberían preocuparse demasiado por esto ya; en realidad, se trata de evitar refactorizar el texto existente una y otra vez. - xaosflux Talk 11:45, 16 de enero de 2021 (UTC)
  • Como mínimo, las pancartas deben reducirse y eliminar las banderas u otras imágenes. Las variedades en inglés no siempre siguen cuidadosamente los límites políticos y, en cualquier caso, tenemos WP: FLAGCRUFT para tales situaciones en artículos y, sin embargo, las banderas se envían spam a través de las páginas de discusión. Eliminarlos también ayuda a reducir el espacio y la prominencia de una plantilla que probablemente se ve principalmente cuando se busca explícitamente. CMD ( charla ) 16:47, 17 de enero de 2021 (UTC)
    Estoy de acuerdo en que las pancartas deberían recortarse, pero creo que las banderas en realidad son bastante útiles como taquigrafía visual, por lo que son un elemento que creo que deberíamos mantener. {{u | Sdkb }}  charla 21:15, 14 de febrero de 2021 (UTC)
  • Mi principal preocupación aquí es que los editores de página, editores de plantillas y administradores solo pueden editar los avisos de edición. Entiendo que un bot puede hacer el movimiento inicial, pero ¿cómo vamos a hacer las adiciones de estos en el futuro? No me importa si la consecuencia es que estos avisos se vuelven más raros, pero en ese caso debería ser una elección deliberada y no solo un descuido. Tampoco creo que sea un buen uso del tiempo para aumentar significativamente la cantidad de WP: TPER triviales con cambios en los avisos de engvar. - Trialpears ( charla ) 21:46, 11 de febrero de 2021 (UTC)
    Trialpears , como mencioné un poco en mi voto!, Veo esto como un problema subyacente: hay muchas situaciones en las que cualquiera que haya sido confirmado automáticamente debería poder editar el aviso de edición de una página, pero no puede (no por consenso editorial, pero solo por algo sobre la estructura técnica de back-end de editnotices). Ese es un problema que deberíamos resolver (y si esto pasa, podría empujarnos a hacerlo), pero no creo que debamos ponernos en desventaja aquí y rechazar esto por eso. Hacer eso oscurecería el nivel de necesidad de resolver el problema y nos daría más trabajo en el futuro una vez que se resuelva. {{u | Sdkb }}  charla 00:12, 13 de febrero de 2021 (UTC)
    Siento que, en general, sería una buena idea, pero todavía veo algunas razones para la protección. El vandalismo en los avisos de edición probablemente no se detectaría la mayor parte del tiempo e incluso si se detectara, la mayoría de los editores probablemente no estarían familiarizados con cómo resolverlo. Ponerles información errónea podría ser significativamente peor. Sin embargo, definitivamente apoyaría habilitarlo para usuarios confirmados extendidos. En lo que respecta a la implementación, la restricción se rige por MediaWiki: Titleblacklist, que puede cambiarlo fácilmente para requerir confirmación automática. También debería ser posible utilizar un filtro de edición en su lugar, que podría implementar una restricción confirmada extendida en su lugar. - Trialpears ( charla ) 21:26, 16 de febrero de 2021 (UTC)
    Sdkb No veo ningún problema con mantener los avisos de edición para las personas que pueden anular la lista negra; la necesidad de editar los avisos de edición es bastante nicho y, en la mayoría de los casos , deberían usar plantillas que no están en la lista negra y, por lo tanto, pueden editarse.
    Siempre que las solicitudes de edición se cumplan rápidamente, está bien. ¿Quizás más personas deberían solicitar el cambio de página? Elliot321 ( discusión | contribuciones ) 07:29, 3 de marzo de 2021 (UTC)

Protección de cambios pendientes del artículo destacado de hoy [ editar ]

La idea de aplicar automáticamente WP: Semiprotection a WP: El artículo destacado de hoy (TFA) ha sido aplastado hasta la muerte; vea WP: PERENNIAL # Protecting Today's Featured Article en la página principal . Creo que la discusión más reciente fue en julio de 2020, en WT: Artículo destacado de hoy / Archivo 14 # Pregunta sobre protección . El argumento clave (al menos para mí) es que lo último que queremos hacer es desalentar a los nuevos editores.

Sin embargo, cada vez que un artículo con un toque de controversia es TFA, aparece en WP: ANI . Para ver algunos ejemplos recientes, consulte Wikipedia: Tablón de anuncios de administradores / IncidentArchive1057 # El Holocausto en Eslovaquia: TFA sujeto a vandalismo continuo (27 de enero de 2021), Wikipedia: Tablón de anuncios de administradores / IncidentArchive1057 # Guadeloupe amazon: TFA de hoy sujeto a vandalismo continuo (28 de enero de 2021) . 2021), Wikipedia: Tablón de anuncios de los administradores / IncidentArchive1057 # Pyramid of Nyuserre: el TFA actual está sujeto a vandalismo persistente (30 de enero de 2021) y WP: ANI # La profecía de Hitler: el TFA sufre un vandalismo continuo (30 de enero de 2021). También pueden publicarse en WP: AIV, que es menos fácil de buscar. No he visto informes de problemas con los artículos de WP: DYK .

Durante esa última discusión, sugerí que TFA podría ser WP: cambios pendientes-protegido solo mientras esté en la página principal; y esta idea parece nueva. Los IP y los editores no confirmados podrían publicar, incluso si sus contribuciones no se mostraban de inmediato; y el vandalismo podría despacharse rápidamente donde corresponde. Se podría alentar a los representantes de un TFA a ayudar a los patrulleros regulares de cambios pendientes. También resolvería el problema de averiguar cuándo ocurrió el vandalismo y quién lo hizo (un problema perenne con la pequeña cantidad de vandalismo con el que trato, en su mayoría relacionados con enlaces a páginas DAB, que pueden estar escondidos detrás de varias ediciones buenas recientes y requieren copiar y pegar de la última versión buena). No debería ser técnicamente difícil de implementar; podría ser parte del script que agrega artículos y los elimina de la página principal. A algunos otros editores parece gustarles la idea,y se sugirió que abriera una discusión aquí. (Para que conste, estoy a favor).Narky Blert ( charla ) 10:36, 2 de febrero de 2021 (UTC)

Notaré que una de las principales razones de los rechazos de auto semi en TFA en el pasado es dar la impresión de que Wikipedia no es tan libre de editar al tener nuestra página más visible no editable para la mayoría de la audiencia de TFA. La protección de cambios pendientes evita esto al permitir que los usuarios realicen la edición, incluso si hay un ligero retraso en la publicación en vivo, por lo que sería un compromiso decente entre el acceso sin restricciones y la máxima accesibilidad para nuestra página más visible, y evitar el desperdicio de la el tiempo de la comunidad y el riesgo potencial de que se publique contenido inadecuado para que todos lo vean. Saludos, Usuario: TheDragonFire300 . ( Contáctame | Contribuciones ). 11:01, 2 de febrero de 2021 (UTC)
Como reflexión adicional, el texto de la plantilla de protección debe estar hecho a medida para los AGT y ser acogedor. Narky Blert ( charla ) 13:35, 2 de febrero de 2021 (UTC)
Y otro - WP: ANI # Pacific swift - Los TFA de hoy reciben un alto nivel de vandalismo de IP (4 de febrero de 2021). Narky Blert ( charla ) 08:59, 5 de febrero de 2021 (UTC)
Otro, para el que se rechazó la protección: WP: ANI # Cheadle Hulme: los TFA de hoy reciben un alto nivel de vandalismo de IP (5 de febrero de 2021). Narky Blert ( charla ) 11:42, 7 de febrero de 2021 (UTC)
Esta es cada edición realizada a Cheadle Hulme durante su día en TFA . Veo un gran total de dos vándalos de IP, uno de los cuales hizo dos ediciones y otro hizo una, mientras que todas las demás ediciones de IP son constructivas. Si algún administrador lo hubiera protegido en esas circunstancias, entonces, a menos que haya algo que me haya perdido, lo habrían llevado instantáneamente a Arbcom por abuso de administrador. -  Iridiscente 12:37, 7 de febrero de 2021 (UTC)
No soy administrador y no tengo ningún comentario sobre si alguna página en particular debería o no estar protegida. Sin embargo, he sentido que es correcto publicar aquí todas las publicaciones relevantes de ANI desde que abrí esta discusión, sin importar si ayudan o perjudican mi propuesta. Toda la evidencia es importante para llegar a un consenso. (No he monitoreado WP: AIV o WP: RFPP , lo que sería mucho más difícil). Narky Blert ( charla ) 20:10, 19 de febrero de 2021 (UTC)
Otro, WP: ANI # Apollo 14: los TFA de hoy reciben un alto nivel de vandalismo de IP y contenido sin fuente (8 de febrero de 2021). Narky Blert ( charla ) 12:53, 9 de febrero de 2021 (UTC)
Y otro - WP: ANI # Bernard A. Maguire - El TFA de hoy sufrió un vandalismo persistente (11 de febrero de 2021). Narky Blert ( charla ) 00:23, 12 de febrero de 2021 (UTC)
WP: ANI # Vandalismo en la moneda TFA Grant Memorial (12 de febrero de 2021). Narky Blert ( charla ) 05:42, 13 de febrero de 2021 (UTC)
Otro - WP: ANI # Vandalism on Saturn (revista) (14 de febrero de 2021). Narky Blert ( charla ) 07:30, 14 de febrero de 2021 (UTC)
Entrega de hoy - WP: ANI # Vandalism on Silesian Wars (15 de febrero de 2021). Cuando este fue reportado a ANI, solo le quedaban un par de horas en la página principal. Cluebot y algo así como seis editores registrados ya se habían ocupado de las ediciones; agregue el administrador protector, y eso es mucho trabajo.
Vi algo que no había notado antes: Usuario: TFA Protector Bot había atascado {{ pp-move }} en el artículo el 26 de enero, con vencimiento automático a la medianoche del 15 de febrero. Narky Blert ( charla ) 17:34, 16 de febrero de 2021 (UTC)
@ Narky Blert : Desde hace varios años, ha sido normal que todos los próximos TFA (que aún no tienen protección de movimiento) reciban una protección de movimiento a corto plazo, que expirará en el momento en que el artículo deje de ser TFA. Hasta noviembre de 2013 fue un proceso manual; desde entonces se le ha encomendado a TFA Protector Bot, consulte el BRFA . Este prot generalmente se aplica con algún tiempo de anticipación (creo que poco después de que se haya aprobado el espacio del calendario), consulte el registro del bot ; y el uso de es complementario a eso. - Red rose64 🌹 ( hablar ) 22:33, 16 de febrero de 2021 (UTC){{pp-move}}
No conocía ese procedimiento (por eso lo mencioné), pero me parece excelente. Incluso un movimiento de buena fe de un artículo revisado y en cola sería perturbador, en el esquema general de las cosas. No queremos redireccionamientos en la página principal.
Además - WP: ANI # Vandalismo en la historia meteorológica del huracán Dorian (19 de febrero de 2021). Narky Blert ( charla ) 20:00, 19 de febrero de 2021 (UTC)
Y otros dos: WP: ANI # Vandalism on SS Mauna Loa (19 de febrero de 2021) y WP: ANI # Multiple IPs agregando pornografía o imagen ofensiva en un artículo supuestamente de TFA (20 de febrero de 2021). En el segundo, cuento (entre otras reversiones) siete WP: REVDELs mientras el artículo estaba en la página principal. Narky Blert ( charla ) 00:53, 21 de febrero de 2021 (UTC)
Otro - WP: ANI # Vandalism on Margaret (cantante) (23 de febrero de 2021; también mencionado por Levivich, a continuación), que ilustra un problema. Un administrador WP: SILVERLOCKed la página durante 3 días (lo que en mi opinión es demasiado tanto en duración como en nivel); un más cercano que no es administrador pensó que el problema debería haberse publicado en WP: RFPP not ANI. Narky Blert ( charla ) 21:49, 24 de febrero de 2021 (UTC)
@ Narky Blert : Fui yo quien cerró ese hilo; en ese caso, ya había un duplicado en WP: RFPP , por lo que tener un hilo ANI parecía redundante. Saludos, Usuario: TheDragonFire300 . ( Contáctame | Contribuciones ). 04:57, 2 de marzo de 2021 (UTC)
Se acepta ampliamente que la PC no funciona / no es práctica en páginas muy editadas. Es por eso que nadie lo sugiere, probablemente. - Izno ( conversación ) 15:44, 2 de febrero de 2021 (UTC)
Esto es algo que se demostró durante el intento de puerta trasera de la PC , por los artículos de Barack Obama y George W. Bush . El volumen de ediciones era tan alto que la cola de esos artículos estaba perennemente atrasada, por lo que se acordó y todavía se acordó que la PC no es adecuada para páginas que verían grandes volúmenes de ediciones, algo que sucedería con TFA por una cuestión de curso. - Un pequeño Bori azul v ^ _ ^ v Se necesita un hombre fuerte para negar ... 16:43, 2 de febrero de 2021 (UTC)
Al menos los AGT considerados en esta discusión. Últimamente he visto algunos TFA bastante tranquilos. - Izno ( charla ) 17:17, 2 de febrero de 2021 (UTC)
Desafortunadamente, sospecho que el conjunto de TFA que sería lo suficientemente silencioso para que funcione la PC es casi idéntico al conjunto de TFA donde no se necesita la PC. Thryduulf ( conversación ) 01:30, 3 de febrero de 2021 (UTC)
Como partidario de la propuesta y un PCR activo, no creo que esto sea insuperable para la mayoría de los TFA. Observo que los dos ejemplos dados son temas muy políticos, uno de los cuales era en ese momento Presidente de los Estados Unidos y el otro había sido hace menos de un mandato completo. Vaticidalprophet ( charla ) 06:04, 3 de febrero de 2021 (UTC)
Estoy en contra de la protección preventiva de cualquier tipo, especialmente los cambios pendientes que hacen más trabajo para los voluntarios y rara vez son útiles. - Wug · a · po · des 1:53 3 de febrero 2021 (UTC)
  • Apoye algún tipo de protección. Es inaceptable que los editores (¡muy predeciblemente!) Destrocen artículos como El Holocausto en Eslovaquia mientras están en la página principal. Esto disminuye nuestra reputación mucho más de lo que haría cualquier protección. ( t · c ) buidhe 04:16, 3 de febrero de 2021 (UTC)
  • Debo señalar que "muy activo" es un límite bastante bajo: PCR comienza a tener problemas reales mucho antes, digamos, que los editores suelen tener conflictos de edición. Tampoco estoy seguro de cuán precisa es la predicción de la tasa de edición probable de un TFA que podamos hacer. Obviamente, podemos predecir los segmentos "muy activos" y "no es probable que se editen mucho", pero habría una categoría media grande que es difícil de ordenar. Como tal, sigo creyendo que la PCR sigue siendo claramente problemática para cualquier uso de TFA que realmente justifique la PCR. Nosebagbear ( charla ) 07:35, 3 de febrero de 2021 (UTC)
  • Para ser honesto, no estoy totalmente en contra de esto. La utilidad de los cambios pendientes es diferente de la semiprotección: el objetivo no es reducir la carga de trabajo para los administradores y los patrulleros de cambios recientes (como otros han señalado correctamente anteriormente, los cambios pendientes efectivamente hacen lo contrario), sino más bien, prevenir el vandalismo. de ser visto por los lectores y, por lo tanto, posiblemente desprestigiar el proyecto. De hecho, si mi memoria no me falla, durante un breve período hace unos años, en realidad comenzamos a poner de manera preventiva la protección de PC en el TFA después de un WP: ANdiscusión debido a un LTA particularmente desagradable que reemplazaría las imágenes de los TFA por otras extremadamente impactantes. Los problemas tradicionales con PC en páginas muy editadas no parecen ser una gran preocupación aquí porque la protección solo duraría un día, y la mayoría de los TFA no parecen editarse con tanta frecuencia que los grandes atrasos podrían convertirse en un problema. Como mínimo, probablemente apoyaría un período de prueba para esta idea. Mz7 ( conversación ) 07:53, 3 de febrero de 2021 (UTC)
    Pensando en esto un poco más, creo que la pregunta relevante sería con qué frecuencia el vandalismo permanece sin ser detectado por más de, digamos, un minuto mientras se encuentra en el TFA. Los cambios pendientes funcionan mejor en artículos donde el vandalismo tiene dificultades para revertirse rápidamente, y ahora que lo pienso, debido a que la TFA ya tiene muchos ojos puestos en él en general, puede darse el caso de que la mayor parte del vandalismo ya se haya revertido en segundos, haciendo que la necesidad de cambios pendientes sea discutible. Mz7 ( conversación ) 08:02, 3 de febrero de 2021 (UTC)
Por lo que puedo decir, el vandalismo de TFA rara vez, si es que alguna vez, se revierte en segundos. He escuchado promedios de alrededor de 10 a 15 minutos, lo cual es suficiente para ser problemático para esos artículos, especialmente con vandalismo pesado o grotesco. Vaticidalprophet ( charla ) 11:39, 3 de febrero de 2021 (UTC)
Mirando las historias de edición de los artículos que mencioné en el párrafo inicial (una muestra estadística muy pequeña): si ClueBot lo detecta, en segundos; si es humano, de 1 a 40 minutos (mediana 8). Narky Blert ( charla ) 14:24, 3 de febrero de 2021 (UTC)
Creo que la pregunta relevante sería con qué frecuencia el vandalismo permanece sin ser detectado por más de, digamos, un minuto mientras estoy en el TFA. Esta es la pregunta crucial para mí. Si nuestro objetivo es evitar la interrupción del lector, necesitamos saber cuánto vandalismo está molestando a los lectores actualmente. No creo que una versión de prueba cambie nuestra capacidad de ver eso, solo necesitamos a alguien que procese los números del historial de la página. También se podría cruzar con las visitas a la página del día para estimar la cantidad de lectores que realmente vieron el vandalismo, por ejemplo, este vandalismo duró 5 minutos, por lo que con un total de 60 mil visitas a la página ese día --- 5 mil personas probablemente vi esto en lugar del artículo. En mi experiencia, es como usted lo describe con los ojos agregados que brindan reversiones más rápidas, pero conocer el promedio y otras estadísticas sería útil y muy posiblemente cambie mi opinión. Si la protección de PC realmente es un beneficio sustancial, estaría dispuesto a apoyar su uso en TFA. Al menos permite a los usuarios sin cuentas editar, y si elaboramos un mensaje agradable como sugiere Narky, podría minimizar la posibilidad de que un novato muerda . Así que mi principal preocupación en este caso es la utilidad, porque pocas veces he visto que una PC resuelva más problemas de los que causó. - Wug · a · po · des 20:13 3 de febrero 2021 (UTC)
(Supongo que las matemáticas en su ejemplo no deben tomarse literalmente, pero 5 minutos de 60,000 páginas vistas son aproximadamente 209 vistas; 5,000 serían 60,000 por hora . Una limitación de este enfoque es que el vandalismo dura más cuanto menos se ve la página es, y las páginas vistas varían según las zonas horarias en las áreas de donde provienen la mayoría de nuestros lectores. Pero creo que alguna API en algún lugar puede brindarle páginas vistas por hora.) - Bilorv ( charla ) 20:43, 4 de febrero de 2021 (UTC)
  • Admite la protección de cambios pendientes como prueba : TFA se diferencia de otras páginas muy visitadas en que es muy probable que haya un editor muy activo al que le apasione el artículo (el que acaba de promocionarlo a FA), y la actividad se limita a 24 horas (tal vez los próximos días también, mientras todavía está vinculado en la página principal). Realmente no puedo hablar por todos esos editores (solo he sido esa persona una vez) pero tal vez algunos podrían ver todos los cambios al menos después de que el polvo se haya asentado y recopilar cualquiera de los cambios que sean productivos. Un contraargumento es que los TFA son, bueno, artículos destacados y, por lo tanto, es mucho menos probable que tengan problemas que los usuarios nuevos y no registrados puedan resolver. Pero es probable que todavía haya pequeñas mejoras en la prosa que cabría esperar en el período del TFA. Una alternativa tal vez sea semiproteger preventivamente solo algunos AGT según el tema. - Bilorv ( conversación ) 20:43, 4 de febrero de 2021 (UTC)
  • Soporte Se hacen pocos cambios útiles, el vandalismo es un problema serio no por la cantidad de vándalos sino por el ojo morado que nos queda por permitirlo en la portada. El volumen de cambios de los que estamos hablando no es muy grande. Así que este es un excelente uso de la PC. Hawkeye7 (discutir) 04:33, 5 de febrero de 2021 (UTC)
  • Prueba de soporte , en mi opinión, este es el equilibrio ideal entre preservar tanto la integridad de nuestro mantra de "cualquiera puede editar" y la calidad de nuestros artículos destacados. Tiendo a estar de acuerdo con Hawkeye en que "se realizan pocos cambios útiles", hasta el punto en que la cantidad de vandalismo o ediciones inútiles supera en gran medida a la corrección ortográfica aleatoria ocasional (y de todos modos sería mejor discutir cualquier edición / error importante en la página de discusión) . Pero de cualquier manera, esta protección podría abordar tanto el vandalismo como algunas ediciones útiles. Aza24 ( charla ) 09:07, 5 de febrero de 2021 (UTC)
    • Solo quisiera reafirmar mi apoyo; cuando mi Retrato de un músico fue a TFA hace un par de días, hubo mucho vandalismo, casi todos los cuales podrían haber sido prevenidos por PC; las otras correcciones y ediciones proses fueron realizadas por usuarios que no habrían sido restringidos por PC. Ciertamente vale la pena hacer una prueba. Aza24 ( conversación ) 23:37, 1 de marzo de 2021 (UTC)
  • (nom) Estoy de acuerdo en que cualquier cambio debe realizarse a modo de prueba.
Mi idea para el texto de la plantilla es similar a: "Bienvenido al artículo destacado de hoy. Es un hecho lamentable que estos artículos atraigan a vándalos. Por lo tanto, los cambios de los nuevos editores son revisados ​​por editores experimentados antes de que aparezcan para que todos los vean. Por lo general, esto solo toma unos minutos. Si está aquí para ser parte de la comunidad cuyo objetivo es mejorar Wikipedia, ¡gracias y feliz edición! Puede encontrar Ayuda: Edición de una guía útil para principiantes. Si está aquí solo para interrumpir - ¡Lárgate contigo! " Narky Blert ( charla ) 18:04, 5 de febrero de 2021 (UTC)
  • Soporte Evitaría la publicación instantánea de material tóxico o con derechos de autor en artículos tan visitados. ~ HAL 333 02:58, 6 de febrero de 2021 (UTC)
  • Al recibir el aviso, todavía no lo he dicho explícitamente aquí, apoyo como una de las partes en la conversación original. Vaticidalprophet ( charla ) 13:53, 6 de febrero de 2021 (UTC)
  • Oponerse . La protección de PC genera una cantidad significativa de trabajo con un beneficio mínimo y no funciona en páginas con un alto volumen de edición; aquellas páginas que atraen suficiente vandalismo como para que la protección valga la pena, también serán aquellas en las que la PC no funcionará. La PC también presenta importantes inconvenientes adicionales además de la acumulación de mantenimiento que genera; no hay forma de agregar un resumen cuando se rechaza una edición, por lo que cuando se desaprueba una edición de buena fe pero inapropiada, no se puede explicar por qué en el resumen de la edición; para problemas de BLP, la PC tiene poco impacto ya que no afecta lo que Google raspa (recogen la revisión más reciente incluso si no ha sido aprobada); aprobar / desaprobar cambios en un artículo a nivel de FA a menudo requiere conocimientos especializados del tema,que el puñado de personas que trabajan enEspecial: Es poco probable que la cola de cambios pendientes tenga; toda la propuesta parece basarse en la idea de que todas, o al menos la mayoría, de las AF estarán en las listas de seguimiento de las personas, lo cual no es el caso. -  Iridiscente 08:00, 7 de febrero de 2021 (UTC)
(Es interesante verte aquí. Literalmente me preguntaba qué pensarías de la propuesta). Por lo que vale, "no hay forma de agregar un resumen cuando se rechaza una edición, por lo que cuando se desaprueba una edición de buena fe pero inapropiada no se puede explicar por qué en el resumen de edición "es incorrecto - el cuadro de resumen de edición es ... eh, la cola de PC está vacía mientras hablamos, por lo que mi plan para tomar una captura de pantalla para" aquí mismo "tendrá que esperar, pero está colocado de manera prominente con un texto gigante en negrita "AÑADIR UN RESUMEN DE EDICIÓN SI LO QUE ESTÁS REVERTIR NO ES VANDALISMO BLATANT". Vaticidalprophet ( charla ) 06:37, 8 de febrero de 2021 (UTC)
En lugar de hacer una captura de pantalla del cuadro de resumen de edición, aquí hay una captura de pantalla de mis contribuciones recientes de PCR que las muestra. Vaticidalprophet ( charla ) 06:42, 8 de febrero de 2021 (UTC)
Es alarmante, como algo independiente, saber que Google está eliminando la revisión más reciente en las páginas de PCP, aunque entendí que tenía un poco de retraso por razones generales de vandalismo (posiblemente es solo que Google tarda unos minutos en eliminar la artículo de nuevo). Sin embargo, este es un problema de Google, no nuestro. No quiero que tengan voz en ninguna de nuestras decisiones de ninguna manera. Necesitan cambiar para adaptarse a nosotros, no al revés. Hay otros motores de búsqueda disponibles. - Bilorv ( conversación ) 00:56, 13 de febrero de 2021 (UTC)
Alrededor de 2014, me dijeron que Google raspaba un sitio web social muy conocido cada 20 minutos. Nuestro objetivo como moderadores voluntarios era eliminar el spam comercial pesado dentro de ese tiempo. IDK si ese es un número típico, pero nuestro líder intentó y no logró que lo aumentaran a 30. Narky Blert ( hablar ) 06:05, 13 de febrero de 2021 (UTC)
  • Soporte El único retraso que esto generaría en términos de PC es una página que debería revisarse regularmente durante el tiempo que dure (y, bueno, el PC no es tan grande en comparación con otros lugares). Y, bueno, si bien es posible que no detenga todo, al menos cualquier edición vandálica (que debería revertirse de todos modos, PC o no) no se mostrará de manera prominente a todas las personas que lleguen allí ... RandomCanadian ( talk / contribs ) 01:21, 12 de febrero de 2021 (UTC)
  • Soporte como revisor de cambios pendientes, creo que la carga de trabajo adicional sería mínima en comparación con los beneficios. Con la cantidad de ojos en la página, los cambios buenos se aceptarán rápidamente, mientras que los malos no se vincularán de manera prominente desde la página principal. Elliot321 ( discusión | contribuciones ) 05:57, 14 de febrero de 2021 (UTC)
  • Soporte : esto me parece un compromiso razonable que permite a los IP editar TFA y combate el vandalismo. Dicho de otra manera, es el medio menos restrictivo de proteger eficazmente nuestros artículos más destacados. (Proteger un artículo al día ciertamente no abrumará a la PC, y el artículo estará ampliamente en la lista de vigilancia de todos modos). Probemos al menos este esquema: creo que sería efectivo. Auto extraordinario ( charla ) 07:18, 14 de febrero de 2021 (UTC)
  • (nom) Para repetir un punto que hice antes, en caso de que se pierda. Esta idea tiene tanto zanahoria como palo. Proporcionaría un medio para dar la bienvenida rápidamente a los nuevos editores y orientarlos en la dirección correcta. Los editores experimentados saben dónde buscar o pedir ayuda; los novatos, por definición, no lo hacen. Narky Blert ( charla ) 07:50, 14 de febrero de 2021 (UTC)
  • Soporte . Se trata de equilibrar la reputación positiva de Wikipedia como la enciclopedia "cualquiera puede editar", contra la posible reputación negativa de vandalismo e inexactitudes que se introducen y no se detectan. Creo que la protección de cambios pendientes es un compromiso excelente, ya que permite a la gente editar, pero evita que aparezcan tonterías estúpidas en nuestro artículo más destacado del día. ƒirefly ( t · c ) 14:02, 14 de febrero de 2021 (UTC)
    • Cambiar a oposición fuerte después de enterarse de que FlaggedRevs (es decir, el módulo detrás de los cambios pendientes) está efectivamente abandonado, sin que nadie en el equipo de desarrollo de MediaWiki sea responsable de ello, y que tiene varios errores extraños ( phab: T275322 , phab: T275017 ) que aparentemente no se están resolviendo. Lo último que queremos son errores extraños de MediaWiki que se muestran en TFA. ƒirefly ( t · c ) 09:42, 2 de marzo de 2021 (UTC)
  • Soporte como prueba . Estoy de acuerdo con RandomCanadian, un corto período de tiempo con la protección de cambios pendientes no va a generar mucho retraso y con tantos ojos puestos en TFA.
    Sin embargo, me he estado preguntando (que también es la razón por la que estoy votando aquí, por primera vez en Village Pump), ¿a dónde iría uno para sugerir un tipo de protección completamente nuevo? Porque, ¿qué pasaría si, en lugar de poner cambios pendientes en TFA, hubiera una protección de "cambios retrasados"? Básicamente, serían cambios pendientes, pero con aprobación automática después de un período de tiempo establecido. Establezca el tiempo en algo un poco más largo que la duración promedio que se necesita para revertir el vandalismo, y apuesto a que reduciría drásticamente la carga de trabajo en los días de mucho vandalismo sin contribuir a una acumulación de cambios pendientes. Esta sería una protección solo para TFA (un caso de una página con alta visibilidad / tráfico durante un corto período de tiempo). Pero dado que esto debería crearse y no es una cuestión de asignar una protección existente, 'Es más una sugerencia de implementación futura. -Pinchme123 ( charla ) 01:27, 18 de febrero de 2021 (UTC)
    @ Pinchme123 : Las solicitudes de funciones deben enviarse a Phabricator . - Red rose64 🌹 ( hablar ) 14:26, 18 de febrero de 2021 (UTC)
@ Redrose64 : Gracias por indicarme Phabricator, ya que no lo sabía de antemano. Pero mi pregunta no se trata de "enviar" una solicitud de función, sino de sugerir una, para discutirla antes de solicitarla. Veo poco sentido en solicitar una nueva función de marca sin tener una discusión sobre sus méritos, especialmente cuando las solicitudes de funciones parecen realizarse fuera de WP (dado que Phabulator es simplemente una entidad afiliada de Wikimedia, y tuve que crear una nueva cuenta solo para ver la página de creación de solicitudes de funciones). Entonces, ¿a dónde podría ir para sugerir la función para debatir? - Pinchme123 ( charla ) 16:16, 18 de febrero de 2021 (UTC)
  • Oponerse , per iridiscente, y también debido al principio general de usar TFA para resaltar el principio de "cualquiera puede editar". Editar con retraso no es lo mismo que editar con un impacto inmediato, y usar PC en una página tan prominente perjudicaría la contratación. - Yair rand ( conversación ) 06:25, 18 de febrero de 2021 (UTC)
  • Comentar . Estoy en el campo opuesto instintivo según Iridescent & Yair rand, pero puedo ver el problema de adaptar nuestros procesos a medida que evolucionamos de "la enciclopedia que cualquiera puede editar " a " la enciclopedia que cualquiera puede editar". Si queremos usar el TFA para el reclutamiento, entonces la edición debe ser visible (casi) de inmediato; más de 30, creo, quitarían ese pequeño estallido de alegría que me hizo adicto a la edición aquí. Creo que uno de los principales Los problemas a los que se enfrenta Wikipedia a medida que madura son la erosión de la base de editores, ya que cada vez es más difícil poner un pie en la puerta como nuevo editor. ¿Hay alguna evidencia de que los novatos comiencen a editar a través del TFA? He visto varios nuevos editores convertidos a través de ITN, pero rara vez otras secciones de la página principal. Mis DYK ocasionalmente han tenido ediciones importantes o de corrección de errores tipográficos por parte de enlaces rojos o IP que están claramente interesados ​​en el tema, e incluso muy ocasionalmente he tenido comentarios de agradecimiento u oprobio de las direcciones IP.Personalmente, detesto los cambios pendientes y casi nunca acepto revisiones importantes porque me impone la responsabilidad de apoyarlos y sé que otros tienen el mismo problema. ¿Existe algún mecanismo mediado por bot que pueda autoaceptar inmediatamente cualquier cosa que parezca de buena fe y no sea obviamente problemática? ¿Se puede configurar Cluebot para que se ejecute en cada edición de TFA inmediatamente?Espresso Addict ( charla ) 12:19, 18 de febrero de 2021 (UTC)
  • Apoye firmemente intentar algo después de ver a la TFA de hoy, Margaret (cantante) , ser objeto de vandalismo incesantemente, lo que generó otro hilo de ANI . Creo que el trabajo de combatir el vandalismo en los TFA es mayor que el trabajo que implica proteger el artículo, y el detrimento del vandalismo en los TFA es mayor que el de no permitir que todos lo editen instantáneamente. No estoy seguro de si es PC, semi o algo más, pero Something Must Be Done ™. Apoyaría una prueba de esta o cualquier tipo de protección. O incluso un ensayo de PC y semi, como una prueba A / B . A lo que me opongo firmemente es a resignarnos a "bueno, así es como es" y no intentar nada. Oponerse firmemente a no intentar nada . Levivich acosar / sabotear 22:44, 23 de febrero de 2021 (UTC)
  • ApoyoComo es un artículo destacado, el cálculo de costo-beneficio aquí es muy diferente al de la mayoría. Los recién llegados vandalizan muchos artículos, pero también hacen buenas ediciones para compensar eso. Para los artículos destacados, la probabilidad de que un recién llegado haga una edición buena y constructiva se reduce en gran medida (en función del bajo potencial de mejora del artículo como uno destacado), mientras que el hecho de que esté en la página principal significa que la cantidad de vandalismo aumenta sustancialmente. Personalmente, apoyo la protección de cambios pendientes en todos los artículos destacados debido al beneficio reducido que puede aportar un recién llegado que los edita. Muchos artículos destacados han disminuido significativamente en calidad con el tiempo, ya que para un artículo prácticamente terminado es mucho más probable que cualquier edición por parte de los recién llegados sea inútil.Creo que la gente está sobrestimando la satisfacción que obtiene la gente al ver su cambio de inmediato; Siempre que estén al tanto de la situación de cambios pendientes, lo que más importa es el hecho de que tu trabajo se publique en absoluto, no la hora exacta. Charla de Zoozaz1 22:00, 24 de febrero de 2021 (UTC)
  • Soporte Los AGT más recientes siguen un patrón similar al Oryzomys gorgasi , el AGT del 26 de febrero. Ese día hubo 62 ediciones. De ellos, 27 (aproximadamente el 44%) eran de direcciones IP. Con una excepción que vi, todos fueron actos de vandalismo. Las ediciones 'legítimas' fueron casi todas de usuarios establecidos, y la mayoría de esas ediciones involucraron reparar el daño causado por los vándalos. El principio de "cualquiera puede editar" es, al menos desde mi perspectiva, el medio y debería estar subordinado al fin de crear una enciclopedia basándose en el conocimiento colectivo. Venicescapes ( charla ) 08:07, 28 de febrero de 2021 (UTC)
  • Apoyo ; generalmente funciona bien en dewiki en páginas muy visitadas. Todos los artículos están protegidos para PC en dewiki, lo que genera una larga acumulación de trabajos ( 7500 cambios pendientes ), pero esto no parece ser una preocupación cuando la protección se limita a 24 horas y se realiza de forma selectiva en páginas que es muy probable que se revisen. . ~ ToBeFree ( hablar ) 19:52, 1 de marzo de 2021 (UTC)
  • Soporte por propuesta; sí, cualquiera debería poder editar, lo cual estará en esta propuesta, pero Wikipedia no debería volver a ser víctima de ser llamado el sitio web con imprecisiones que cualquiera pueda agregar. waddie96 ★ ( charla ) 20:44, 1 de marzo de 2021 (UTC)
  • Apoyo Creo recordar haber sugerido esto hace unos años en una de las conversaciones periódicas sobre TFA semiprotector. Evitaría que el vandalismo se mostrara en vivo al tiempo que permitiría la edición de IP. Puede complicarse con muchas ediciones, pero vale la pena probarlo de todos modos. ~ ONUnicorn ( Charla | Contribuciones ) resolución de problemas 20:57, 1 de marzo de 2021 (UTC)
  • No me gusta mucho la protección y detesto los cambios pendientes. Pero tal vez sea el momento de alejarse de TFA como nuestro modelo principal de "cualquiera puede editar" y buscar otras formas de atraer nuevos editores (TFA realmente no es el mejor lugar para editar pruebas). Preferiría semi a PC, pero no me opondré a la propuesta. - Kusma ( t · c ) 21:25, 1 de marzo de 2021 (UTC)
  • Soporte . Prefiero semi sobre PC. Mi primera preocupación es el lector, LUEGO el editor. Dennis Brown - 2 ¢ 22:26, ​​1 de marzo de 2021 (UTC)
  • Respaldo porque servirá mejor a los lectores. TFA recibe mucho tráfico y es un flaco favor para los lectores si encuentran el artículo mientras el vandalismo es visible. Schazjmd  (charla) 22:34, 1 de marzo de 2021 (UTC)
  • A regañadientes , creo que la PC es mala, está rota y no es muy útil. Creo que semi es superior en todos los casos. Sin embargo, dado que hemos decidido no la semiprotección para FA durante años, me conformaré con PC. Creo que es ridículo que no queramos usar semi en FA. Nos hemos quedado atrapados en una trampa de reglas. Está escrito que la protección solo debe usarse después de que se produzca una interrupción, por lo que esperamos hasta que veamos la interrupción. ¡Pero ahora cortamos a la letra de la ley, no al espíritu! El espíritu es prevenir la interrupción. Claro, para la mayoría de los artículos, no podemos saber cuándo ocurrirá la interrupción. Pero los artículos destacados son objeto de vandalismo como un reloj. Mostrar repentinamente una página a 10 millones de personas adicionales al día (¡incluidos nuestros LTA!) Hace que sea casi seguro que sean vandalizados. Una pizca de WP: IARahorraría mucho tiempo y frustración. TLDR: la semiprotección sería superior, pero me conformaré con PC. CaptainEek edita Ho Cap'n! ⚓ 22:55, 1 de marzo de 2021 (UTC)
  • Comentar y oponerse . La capacidad de crear ediciones instantáneas se encuentra en el corazón de este proyecto. Y creo que la primera incursión de muchos editores en Wikipedia es a través de intentos de edición principal. Es nuestra alfombra de bienvenida. Ver su cambio en vivo instantáneamente genera emoción y confirma instantáneamente a los recién llegados que sus sospechas sobre cómo funcionan las cosas ("cualquiera puede editar") eran válidas. Sí, esto incluye muchas ediciones de vandalismo inmaduras. Pero esas cosas tienden a ser estúpidas como la blasfemia insertada de manera muy visible. Pero incluso esto ayuda a generar buenas ediciones nuevas para intentar solucionarlo. En otras palabras, la naturaleza del "salvaje oeste" de la página principal es una forma importante de involucrar a los nuevos usuarios que necesitamos. E incluso algunos de los vándalos se convierten en buenos editores a medida que maduran.Usar PC hace que sus primeras ediciones sean aburridas y la gente tiende a no quedarse por cosas aburridas.Jason Quinn ( charla ) 02:22, 2 de marzo de 2021 (UTC)
  • Oponerse al uso de PC para TFA , pero admitir casi cualquier otra forma de protección (semi, extendida confirmada, etc.). En mi opinión, cambios pendientes es una abominación que no debería usarse en absoluto, en ningún artículo, nunca. Aumenta la cantidad de trabajo innecesariamente y hace que los editores sean responsables de las ediciones de otra persona. También es extremadamente confuso y difícil de entender como característica, lo que para el uso futuro de TFA lo hace inaceptable. TFA será visto y editado por muchos editores sin experiencia. No debemos confundirlos con una monstruosidad como Cambios pendientes. En su lugar, solo semiproteja TFA. Nsk92 ( conversación ) 02:47, 2 de marzo de 2021 (UTC)
  • Oponerse a. Parece que el viento sopla con fuerza en una dirección en este caso, pero mi opinión es que esto parece una solución exagerada en busca de un problema, cuyo problema propuesto creo que es sustancialmente mínimo por la naturaleza misma del contexto. Si los TFA obtienen algo de tráfico adicional de los IP y los editores neófitos, también obtienen un mayor escrutinio por parte de una gran parte de la comunidad durante el mismo período de 24 horas que están en la página principal. Además, estos artículos tienden a ser un poco más sólidos y reflejan una edición comprometida que el artículo promedio. En resumen, no veo que agregar cambios pendientes hará una diferencia sustancial en la protección del artículo contra ediciones erróneas, de mala fe o problemáticas durante el transcurso de su día de estado destacado. Mientras tanto,parece absolutamente seguro que tendrá un impacto en lo que tradicionalmente ha sido uno de los beneficios percibidos del artículo destacado: la contratación de editores.
De hecho, yo diría que tener este proceso mediante el cual los nuevos editores son acorralados en un artículo diferente cada día (qué artículo representa estándares editoriales decentes) y ese espacio se convierte en el primer lugar en el que pueden apreciar el placer de contribuir a la enciclopedia y disfrutar de la sensación inmediata de ver esos cambios en vivo, mientras que al mismo tiempo enfoca la supervisión de la comunidad en ese espacio de artículos de una manera orgánica, todo suena precisamente como el equilibrio que queremos establecer y por qué esto es un "no está roto, no lo arregles" tipo de situación. Además, los TFA con frecuencia se benefician de la función de súper multitud de fuentes de la atención que reciben: la gran mayoría de las ediciones de IP son beneficiosas, no perjudiciales, así que ¿por qué engordar los trabajos al tener una cola de ediciones pendientes (potencialmente superpuestas)?Y esas colas no siempre se abordan con prontitud: yo mismo soy un revisor de cambios pendientes y he registrado una gran cantidad de trabajo en el área en los últimos años, y puedo decirles que la cola que se está abordando es algo bastante variable. con respecto tanto al tema del artículo como a la hora del día. Por último, este no es el escenario típico (un artículo intrínsecamente problemático) en el que esta forma de protección generalmente se considera más justificada.este no es el escenario típico (un artículo intrínsecamente problemático) en el que esta forma de protección suele verse como la más justificada.este no es el escenario típico (un artículo intrínsecamente problemático) en el que esta forma de protección suele verse como la más justificada.
En resumen, y con respecto a los proponentes y partidarios anteriores, el análisis de costo-beneficio va fuertemente en contra de la propuesta, tal como yo la veo. S N O w rap de let 04:28 2 de marzo 2021 (UTC)
Es igualmente probable que un nuevo editor que intente editar un artículo bien establecido (el TFA) estropee algo y reciba un aviso o, peor aún, una advertencia severa y aterradora en su página de discusión. Esto también ignora que la PC todavía permite a los nuevos editores editar el artículo, mientras elimina convenientemente el incentivo para al menos algunos actos de vandalismo / LTA. Ex. (tuve que investigar un poco): TFA de mayo del año pasado : las ediciones revisadas son un vándalo de LTA bien conocido (lo mismo que para la mayoría de los artículos en Wikipedia: artículo destacado de hoy / mayo de 2020... - Ya sé, esta discusión no es una idea nueva); después de la protección de la PC, la LTA se detuvo, aunque aún permitía otras ediciones que no eran de CA (un poco fueron actos de vandalismo común, algunas fueron de buena fe pero equivocadas; pero de todos modos, la PC no crea los mismos problemas que la semiprotección). Si bien es posible que la PC no sea eficaz en algunos artículos, o incluso en la mayoría, en el TFA probablemente sería lo mejor de ambos mundos: no mostrar vandalismo a nuestros lectores, al tiempo que se permite la intervención de nuevos editores. Saludos, RandomCanadian ( charla / contribuciones ) 05:06, 2 de marzo de 2021 (UTC)
  • Soporte . Usar PC en TFA no es realmente una idea nueva. Yo mismo y otros administradores lo hemos aplicado preventivamente muchas veces para protegernos contra el abuso a largo plazo o en reacción al vandalismo. Estas fueron situaciones de emergencia que requirieron salir de la política y la falta de consenso, pero cada vez que yo sepa, no vimos ninguno de los problemas que otros citan con frecuencia cuando cuestionan el uso de PC en TFA. Específicamente, hay suficientes ojos y actividad en este artículo que no tiene mucho en detrimento de la acumulación. Proteger uno de los artículos más visibles de la desfiguración, sin dejar de permitir que los nuevos usuarios contribuyan, es una situación en la que todos ganan y, francamente, ha estado pendiente desde hace mucho tiempo. - Charla MusikAnimal 02:09, 3 de marzo de 2021 (UTC)

RFC: En caso de que se elimine cierto contenido del cuadro de sucesión [ editar ]

¿Deberíamos eliminar el contenido del cuadro de sucesión como el siguiente? Ejemplos: "Primer ministro británico de mayor edad" . ¿Qué dicen todos ustedes? GoodDay ( charla ) 21:57, 4 de febrero de 2021 (UTC)

Encuesta (casillas de sucesión) [ editar ]

  • Sí . No deberíamos tener ninguna de esas trivialidades en cajas de sucesión. A menudo hay muchas cajas, incluso docenas, y el desorden adicional no ayuda. Sería muy difícil encontrar fuentes confiables que discutan cómo James Callaghan "sucedió" a Alex Douglas-Home como el primer ministro británico de mayor edad, y me atrevo a decir que ninguna biografía de ninguno de ellos lo menciona. Surtsicna ( charla ) 22:15, 4 de febrero de 2021 (UTC)
  • Sí . Solo las publicaciones con transiciones (o sucesiones) necesitarían casillas de sucesión. - Kautilya3 ( charla ) 22:56, 4 de febrero de 2021 (UTC)
  • Aquí no . Las trivialidades deben eliminarse, las que no son trivialidades no. Si una sucesión específica es o no trivia, debe discutirse individualmente en un foro apropiado; ese foro no está aquí. Thryduulf ( charla ) 02:21, 5 de febrero de 2021 (UTC)
  • No Como dice Thryduulf que deberían ser los triviales, los no triviales no deberían serlo. Eso debe hacerse caso por caso. - DJSasso ( charla ) 18:03, 5 de febrero de 2021 (UTC)
  • Sí , encuentro que los cuadros de sucesión son innecesarios en general, ya que generalmente duplican el cuadro de información, un cuadro de navegación y / o el texto. Cuando no es duplicativo como este ejemplo, a menudo es trivial que no necesita una caja para sí mismo. Reywas92 Talk 19:36, 5 de febrero de 2021 (UTC)
    • No te gustan , mientras que la presentación clara y coherente me resulta extremadamente útil. Los cuadros de sucesión, los cuadros de información, los cuadros de navegación y la prosa cumplen funciones diferentes, por lo que el mismo enlace que aparece en más de un lugar es algo bueno. Algunas casillas de sucesión deben eliminarse, pero la mayoría no. Cuál es el caso de cualquier caja de sucesión dada solo puede determinarse mediante una discusión de consenso sobre la caja de sucesión en cuestión. Thryduulf ( conversación ) 01:04, 6 de febrero de 2021 (UTC)
  • Sí, y apoyaría deshacerse de todos ellos. Desorden redundante y sin sentido. ¿Por qué no tener cajas separadas para matrimonios, cónyuges y trabajos dispersos a lo largo del artículo mientras estamos en ello? ~ HAL 333 02:50, 6 de febrero de 2021 (UTC)
    • ¿Para qué son redundantes? Los enlaces en prosa y los enlaces en recuadros sucesivos tienen propósitos diferentes, por lo que no son redundantes entre sí. Los recuadros (para cualquier cosa) esparcidos a lo largo de la prosa serían completamente disruptivos para la prosa, por lo que los recuadros de sucesión no se colocan en el medio de la prosa. Thryduulf ( conversación ) 11:58, 6 de febrero de 2021 (UTC)
  • Sí , no estoy seguro de que los necesitemos para puestos, pero definitivamente no para superlativos. Levivich  acoso / sabueso 17:22, 6 de febrero de 2021 (UTC)
    • ¿Todos superlativos? ¿Qué pasa con los edificios más altos y los puentes más largos? Esas me parecen cajas de sucesión extremadamente útiles. Thryduulf ( conversación ) 18:24, 6 de febrero de 2021 (UTC)
  • Comentario : Siento que la validez o trivialidad de las casillas de sucesión debería discutirse caso por caso en su respectiva página de discusión. No estoy seguro de lo que podría lograr una decisión global de una forma u otra sobre cajas de sucesión "triviales", cuando no hace nada para establecer qué es trivial y qué no lo es. PraiseVivec ( charla ) 14:01, 7 de febrero de 2021 (UTC)
  • Sí, para el cuadro de sucesión puramente trivia como "el mayor de los vivos X", a menos que dicho rol sea notable por derecho propio (no estoy seguro de si esto realmente se aplica en cualquier lugar). Elliot321 ( discusión | contribuciones ) 05:54, 14 de febrero de 2021 (UTC)
  • Sí, algunos deben eliminarse. Como mínimo, el espíritu de WP: NAVBOX # 4 parece aplicable: debería haber un artículo de Wikipedia sobre el tema del cuadro de sucesión.— Bagumba ( charla ) 10:11, 22 de febrero de 2021 (UTC)
  • Depende : sí para las "sucesiones" del "primer ministro británico más anciano" como trivia, pero sin una discusión sobre otros dependerá del caso, esto no debe usarse como consenso para eliminar ejemplos no citados. KylieTastic ( charla ) 10:15, 23 de febrero de 2021 (UTC)
  • Sí No se necesitan cuadros de sucesión, en la mayoría de los casos es un duplicado. Sea Ane ( charla ) 21:43, 26 de febrero de 2021 (UTC)
  • Oponerse a decidir este específico aquí, apoyar un replanteamiento general de la sucesión / navboxes y para qué sirven (si es que sirven para algo). La mayoría de los cuadros de sucesión en John Major son menos triviales, pero hay tantos que no son una forma útil de navegar por nada y están ocultos de forma predeterminada (al igual que la cantidad impía de cuadros de navegación). Una vez que un artículo tiene más de tres casillas de sucesión, tienden a dejar de ser útiles. - Kusma ( t · c ) 21:50, 1 de marzo de 2021 (UTC)
  • Sí , muchas casillas de sucesión parecen ser pura trivia. Si no hay un artículo para el tema, no debería existir como un cuadro de sucesión. Nosferattus ( charla ) 04:05, 9 de marzo de 2021 (UTC)

Discusión (cajas de sucesión) [ editar ]

  • ¿Por qué? Ardilla de Ivanvector ( árboles / nueces ) 22:17, 4 de febrero de 2021 (UTC)
    Porque esos no son cargos políticos o de partidos. Son simplemente triviales. GoodDay ( charla ) 22:19, 4 de febrero de 2021 (UTC)
    ¿Por qué necesitamos una política o directriz global o algo al respecto? Si cree que un cuadro de sucesión determinado es trivia, discuta ese cuadro de sucesión específico en algún lugar (página de discusión, WikiProject, TfD, hay muchos lugares). Realmente no entiendo lo que está tratando de lograr aquí: no hay posibilidad de que haya un consenso de que deberíamos tener cajas de sucesión para todo (el décimo clasificado en una carrera del Campeonato Británico de Turismos como un ejemplo incuestionable), pero con la redacción de la discusión no se puede obtener consenso (a favor o en contra) con respecto a ningún ejemplo individual. Thryduulf ( charla ) 02:18, 5 de febrero de 2021 (UTC)
    ¿Espera que haya una discusión separada sobre cada artículo biográfico individual? De todos modos, no sé exactamente sobre qué estás publicando. GoodDay ( charla ) 17:29, 5 de febrero de 2021 (UTC)
    Espero que obtenga un consenso para cada sucesión individual. Eso podría ser en la página de discusión de un artículo o en una discusión centralizada. Por ejemplo, si desea deshacerse del primer ministro británico vivo más antiguo, debe tener una conversación específicamente sobre cómo eliminar el cuadro de sucesión "Primer ministro británico vivo más antiguo" de todos los artículos en los que aparece, con notificaciones para (al menos) la página de discusión. de todos los artículos afectados. En otras palabras, debe hacer exactamente lo mismo que haría con cualquier otro cambio masivo. Thryduulf ( conversación ) 22:26, ​​5 de febrero de 2021 (UTC)
    Eso consume demasiado tiempo. Hay demasiados temas "inútiles" en estos cuadros de sucesión, para revisarlos uno por uno. GoodDay ( charla ) 22:30, 5 de febrero de 2021 (UTC)
    Se podría llevar a cabo una discusión centralizada sobre las casillas de éxito para el primer ministro británico de mayor edad en la charla de Wikipedia: WikiProject Politics del Reino Unido . - Red rose64 🌹 ( conversación ) 23:40, 5 de febrero de 2021 (UTC)
    Pero el ejemplo de los primeros ministros británicos es solo un ejemplo de estos temas triviales en cajas de ayuda. GoodDay ( charla ) 23:41, 5 de febrero de 2021 (UTC)
    El problema es que no tenemos idea de qué otras casillas de sucesión considera triviales, por lo que nosotros (y lo más importante, los editores de los artículos en los que aparecen) no tenemos forma de saber si estamos de acuerdo o en desacuerdo. Si bien el primer ministro británico de mayor edad no parece muy útil, otros, como el primer ministro del Reino Unido, no son triviales, y dónde trazar la línea divisoria entre ellos debe determinarse por consenso. Thryduulf ( charla ) 00:59, 6 de febrero de 2021 (UTC)
    Temas como "más alto Presidente del país" , "más gordo primer ministro de país" , "El más antiguo piloto de Stock Car" , "más joven 100 metros Dasher" , serían temas triviales para Suc-cajas. GoodDay ( charla ) 02:18, 6 de febrero de 2021 (UTC)
    Los dos primeros, sin duda, serían triviales, los dos últimos tal vez; dependería de si se le dio algún significado a esto en fuentes confiables. Sin embargo, una breve lista de temas (que una búsqueda superficial sugiere que no están en uso) que usted considera triviales no va de ninguna manera para abordar el problema en mi comentario. Thryduulf ( conversación ) 18:20, 6 de febrero de 2021 (UTC)
    No sé cuál es tu queja. Quizás sería de ayuda si pusiera ejemplos de temas de cuadros de diálogo que cree que deberían y no deberían eliminarse. GoodDay ( charla ) 18:26, 6 de febrero de 2021 (UTC)
    Mi punto es que deben discutirse individualmente o en pequeños grupos estrechamente relacionados (por ejemplo, quizás cajas de sucesión relacionadas con los primeros ministros británicos). No importa cuántos ejemplos se enumeren aquí, no puede obtener consenso para nada que no se enumere aquí, y cuantos más ejemplos enumere aquí, mayor será la probabilidad de que se produzca un choque de trenes. Thryduulf ( charla ) 00:10, 7 de febrero de 2021 (UTC)
    RFC ya está en pleno apogeo. Veremos cómo termina. GoodDay ( charla ) 00:47, 7 de febrero de 2021 (UTC)
    Consenso de que se deben eliminar algunas, pero no todas las casillas de sucesión, pero no hay consenso para eliminar ninguna en particular; eso requerirá más discusión. Es prácticamente la única forma en que puede terminar. Thryduulf ( charla ) 02:20, 7 de febrero de 2021 (UTC)
    Además, encuentro que los Proyectos Wiki tienden a atraer menos atención. Estaba considerando trasladar otro RFC a Village Pump, por la misma razón. GoodDay ( charla ) 23:55, 5 de febrero de 2021 (UTC)
    Su opinión subjetiva de que algo "consume demasiado tiempo" no le otorga el derecho a ignorar WP: CONSENSUS . Si propone un curso de acción en un WikiProject y anuncia la discusión en las páginas de discusión relevantes, pero nadie opina después de un tiempo razonable (~ semana), entonces puede continuar y eliminar las casillas de sucesión enumeradas en la discusión. Thryduulf ( charla ) 00:59, 6 de febrero de 2021 (UTC)
    ¿Si desea anunciar este RFC en los WikiProjects relacionados? entonces, por supuesto, hágalo. GoodDay ( charla ) 02:18, 6 de febrero de 2021 (UTC)
    Si esta discusión fue realmente sobre casillas de sucesión específicas que sería apropiado, pero como la discusión es en realidad un intento vago y desenfocado de deshacerse de una lista no especificada de casillas de sucesión que a usted (o presumiblemente a cualquier otro editor) personalmente no le gusta, entonces es imposible saber qué proyectos y artículos son relevantes. Por otro lado, si lo hizo dignó a enumerar esas cajas que considere trivia, entonces sería Sospecho convertido rápidamente en un descarrilamiento, debido al gran número de cajas de diferentes editores tendrán diferentes opiniones sobre. Thryduulf ( conversación ) 11:55, 6 de febrero de 2021 (UTC)
    Dado que mis preocupaciones surgieron de la discusión en James Callaghan , uno se vincularía a Political WikiProjects. GoodDay ( charla ) 18:41, 6 de febrero de 2021 (UTC)
Todos deben eliminarse como enlaces spam debido a la duplicación de enlaces e indebidos debido a su tamaño abrumador. Nunca entendí por qué tenemos cajas gigantes con muy pocos enlaces abrumando las secciones. Definitivamente, es un punto de discordia para el editor de contenido que estos cuadros indebidos se envíen automáticamente sin tener en cuenta los enlaces excesivos o injustificados .-- Moxy 🍁 00:04, 6 de febrero de 2021 (UTC)
Muy simplemente porque muchas (no todas) las casillas de sucesión son muy útiles para los lectores. Thryduulf ( charla ) 00:59, 6 de febrero de 2021 (UTC)
No estoy seguro de cómo la duplicación de lnks y las secciones abrumadoras es buena para los lectores. Tenemos protocolos para estos 2 puntos ... simplemente ignorados por los spammers de plantillas. - Comentario anterior sin firmar agregado por Moxy ( charla • contribuciones ) 01:19, 6 de febrero de 2021 (UTC)
Vea mi respuesta en la sección anterior para saber por qué la duplicación no es un problema y no estoy de acuerdo con que la presentación sea abrumadora. El hecho de que algunas casillas de sucesión sean trivia no significa que todas las casillas de sucesión sean spam. Thryduulf ( conversación ) 01:41, 6 de febrero de 2021 (UTC)
Simplemente tendremos que estar en desacuerdo. La práctica de la colocación por sí sola indica que existe un valor muy bajo para la comunidad. Consulte también los enlaces que se encuentran en la parte inferior de los artículos porque duplican los enlaces existentes y el formato no es responsable en ningún otro lugar de los artículos. Es horrible que estos cuadros sean más prominentes que los cuadros de navegación específicos del tema. Es extraño que no se hayan omitido de la vista móvil como basura de carga .-- Moxy 🍁 02:01 , 6 de febrero de 2021 (UTC)
¿Cómo indica la ubicación que tienen un valor bajo? Por supuesto, el formato no es apropiado en ninguna otra parte del artículo; consulte también los enlaces y los enlaces en los recuadros de sucesión tienen un propósito completamente diferente a los enlaces en la prosa. Debe explicar por qué la duplicación es problemática. Thryduulf ( conversación ) 11:55, 6 de febrero de 2021 (UTC)
Es por eso que tenemos una guía sobre esto ... distrae a los lectores de los enlaces que son realmente importantes Wikipedia: Overlink crisis . Son tan abrumadores que los editores los ocultan en plantillas plegables Abraham Lincoln # Enlaces externos . En muchos otros casos, la cantidad de ellos es simplemente abrumadora ... spam de enlaces masivos John A. Macdonald # Enlaces externos .-- Moxy 🍁 17:59, 6 de febrero de 2021 (UTC)
Explicó por qué cree que tener demasiadas cajas es un problema y reiteró su opinión de que algunas cajas tienen un valor bajo (con lo que básicamente nadie está en desacuerdo). Sin embargo no se ha explicado por qué tener ningún cajas es problemático o por qué su posición en el artículo indica esto. Thryduulf ( conversación ) 20:24, 7 de marzo de 2021 (UTC)

RfC: ¿Deberíamos permitir DISPLAYTITLE personalizado? [ editar ]

¿Deberíamos utilizar DISPLAYTITLE personalizado? Tenemos decenas de títulos donde DISPLAYTITLE personalizado sería útil, como thatPower y C Sharp (lenguaje de programación) . El uso de DISPLAYTITLE personalizado nos permitiría eludir estas restricciones y nos permitiría usar cualquier DISPLAYTITLE y desaprobar la plantilla {{título correcto}} Aasim ( talk ) 20:22, 9 de febrero de 2021 (UTC)

  • No. - Izno ( charla ) 22:19, 9 de febrero de 2021 (UTC)
    • @ Izno : ¿te importa elaborar? - El Millo ( charla ) 22:21, 9 de febrero de 2021 (UTC)
      • Considere el posible abuso con títulos arbitrarios. - Izno ( charla ) 22:23, 9 de febrero de 2021 (UTC)
      • No importa el abuso, considere lo difícil que sería identificar el título correcto para poder hacer cosas como el enlace básico de la página. Si no. - Izno ( charla ) 22:36, 9 de febrero de 2021 (UTC)
Debería haber algún sistema que solo permita nombres alternativos "válidos"; actualmente, solo se permiten las modificaciones que dan como resultado el mismo texto (ignorando el formato / normalización). Para C #, necesitaría permitir agregar "#" (tal vez sea razonable codificar como un carácter no admitido), pero también eliminar "Sharp" (más difícil de codificar, porque ya prohíbe ocultar partes arbitrarias del título de la página). Una posibilidad es una función de software separada para que el título solo pueda ser editado por usuarios con cierto permiso, pero no creo que esto obtenga mucho apoyo y sería mucho trabajo para una ganancia bastante menor. Y todavía existe el problema de que el título mostrado no funcionará si lo copia en el cuadro de búsqueda o intenta vincularlo. -  La  Tijereta  ⟨ charla ⟩ 22: 40, 9 de febrero de 2021 (UTC)
@ The Earwig : La eliminación de caracteres del título ya se admite a través del truco font-size = 0, aunque creo que generalmente se considera una mala práctica. - SD0001 ( conversación ) 14:03, 10 de febrero de 2021 (UTC)
De Wikipedia: Nombre de la página # Cambiando el título mostrado , antes era posible ocultar el texto con, display: none;pero esto ya no está permitido. Tiene sentido que haya otras soluciones, pero estoy seguro de que es una mala idea. Por un lado, no estoy seguro de cómo los lectores de pantalla manejarán eso. -  La  Tijereta  ⟨ charla ⟩ 14:39, 10 de Febrero 2021 (UTC)
En teoría, podría haber una lista de sustituciones válidas definidas por expresiones regulares en algún lugar o algo, por lo que la palabra completa "sharp" puede sustituirse por "#" o algo similar. - Aquillion ( charla ) 21:56, 15 de febrero de 2021 (UTC)
  • No básicamente por todos los problemas que Izno ya planteó. - Charla xaosflux 00:10, 10 de febrero de 2021 (UTC)
  • Nunca supe que C # no está en el título correcto. Eso es raro. Si se aprueba esta propuesta, ¿sería esto técnicamente posible actualmente con un cambio de configuración o algo así, o sería necesario escribir el código? De todos modos, me parece que idealmente # debería ser compatible como un personaje en títulos normales, sin usar un truco de título de visualización. ProcrastinationReader ( charla ) 00:16, 10 de febrero de 2021 (UTC)
    @ ProcrastinationReader : Bueno, para habilitar # como un título de página legítimo sin los hacks de DISPLAYTITLE, aún tendría que tratarlo como un caso especial porque # tiene un significado especial en las URL. davidwr / ( charla ) / ( contribuciones ) 00:27, 10 de febrero de 2021 (UTC)
    Sí. Si un # era un carácter admitido en los títulos, ¿ Foo # Bar debería llevarlo al artículo "Foo # Bar" oa la sección "Bar" en el artículo "Foo"? - SD0001 ( conversación ) 14:04, 10 de febrero de 2021 (UTC)
    ¿Cómo lo manejan los artículos? por ejemplo, HC Zemgale / LUA ? ¿O no es válido / (es decir, subpáginas) en el espacio del artículo? ProcrastinationReader ( charla ) 18:48, 12 de febrero de 2021 (UTC)
    La subpaginación está desactivada en el espacio principal (consulte el ejemplo Fate / stay night ). - Izno ( charla ) 19:02, 12 de febrero de 2021 (UTC)
    Esto es técnicamente posible como un cambio de configuración (estableciendo $ wgRestrictDisplayTitle en falso) * Pppery * ha comenzado ... 00:37, 10 de febrero de 2021 (UTC)
  • No son cambios arbitrarios carta blanca , pero estoy abierto a permitirlo caso por caso después de una discusión similar a la de una controvertida discusión de movimiento de página. También estoy abierto a permitir que se permitan clases completamente nuevas de "DISPLAYTITLE", por ejemplo, "allow #", nuevamente, después de un RfC para una discusión similar para cada excepción propuesta. Esto podría implementarse permitiendo DISPLAYTITLE cuando hay un mapeo 1-1 de títulos de página a argumentos DISPLAYTITLE en un "archivo de lista blanca" mantenido por los administradores. Por supuesto, estamos hablando de un cambio de código y el tiempo del desarrollador no es ilimitado. No veo esto como una prioridad, pero si hay tiempo disponible para desarrolladores y probadores, lo preferiría.davidwr / ( hablar ) / ( contribuciones ) 00:24, 10 de febrero de 2021 (UTC)
En mi humilde opinión, creo que el abuso es un poco improbable dado que la mayoría de las personas que visitan Wikipedia para editarlo están aquí de buena fe y probablemente no saben nada sobre cómo funciona "DISPLAYTITLE". También parece que DISPLAYTITLE está oculto profundamente en VisualEditor de todos modos, por lo que no creo que sea probable que ocurra un abuso.
Y jugar con el "TÍTULO DE VISUALIZACIÓN" de una página podría tratarse como una edición disruptiva, del mismo modo que tratamos las guerras de movimiento de página, los comentarios tendenciosos, etc. Aasim ( charla ) 00:55, 10 de febrero de 2021 (UTC)
  • Oponerse Es demasiado molesto y propenso a errores si el nombre mostrado no se puede copiar y pegar en un wikilink o en el cuadro de búsqueda. También puede resultar confuso si hace clic en un enlace en los resultados de búsqueda o en otro lugar y llega a una página con un título diferente. PrimeHunter ( charla ) 15:38, 10 de febrero de 2021 (UTC)
  • Oponerse . Cuando trabajaba para una startup de tecnología musical, uno de nuestros dolores en el trasero eran artistas como Ke $ ha y NIИ. Constantemente escribíamos cosas como esta en casos especiales para que la gente pudiera encontrarlas en las búsquedas. Sí, es molesto que escribir "C #" en un cuadro de búsqueda de wiki lo lleve a C , por lo que tiene que señalar que se dirige a C-sostenido, donde finalmente puede hacer clic en C # (lenguaje de programación) que lo lleva a C Sharp (lenguaje de programación) (en realidad, creo que el último paso podría ser una violación de MOS: DABPIPE ). Pero creo que la alternativa sería peor. - RoySmith (conversación) 15:50, 10 de febrero de 2021 (UTC)
  • oponerse Los caracteres que están permitidos en el título son limitados por buenas razones que yo sepa. Específicamente, # ya tiene un significado en las URL y, por lo tanto, sería un problema real para los enlaces wiki. - GhostInTheMachine me habla a las 18:08, 10 de febrero de 2021 (UTC)
    No se trata de permitir # en wikilinks, sino de permitir DISPLAYTITLE personalizado. Aasim ( charla ) 21:51, 10 de febrero de 2021 (UTC)
    Lo entiendo, pero imagina la diversión que tendrá la gente al intentar escribir un enlace wiki a una página que tiene un carácter # en el título mostrado . ¿Es un enlace wiki de A # B a una página llamada A # B o a un enlace llamado B en la página A? ¿El enlace a una página se llama A-algo-más, pero se muestra como A # B? Si el título de la página se muestra como A # B, ¿cuál debería ser el enlace? - GhostInTheMachine me habla 22:53, 10 de febrero de 2021 (UTC)
  • El problema con esto es que no queremos abuso de suplantación de títulos. ¿Quizás, en ciertos casos, podríamos tener un sistema para mostrar el "título técnico" en una forma menos prominente junto al "título de visualización"? - Yair rand ( charla ) 06:19, 18 de febrero de 2021 (UTC)
    Podríamos adoptar un enfoque como Wiktionary y tener una página de "Títulos no admitidos" donde podemos tener todos los títulos no admitidos enumerados. Entonces la nota técnica sería innecesaria y los vínculos se volverían más claros. Aasim ( charla ) 02:49, 21 de febrero de 2021 (UTC)
    Proporcione un enlace a esa página de Wikcionario. - Red rose64 🌹 ( charla ) 08:28, 21 de febrero de 2021 (UTC)
    Lo que quiero decir es la página de prefijo de "títulos no admitidos" y sus subpáginas son títulos no admitidos. Consulte el wikcionario: Unsupported_titles / Number_sign para ver un ejemplo. Para la página C #, podríamos ubicarla en Títulos no admitidos / C-sharp y luego hacer que JavaScript cambie el título que se muestra a C #. Aasim ( charla ) 08:40, 21 de febrero de 2021 (UTC)
    Parece que hay algo de JavaScript en funcionamiento: al visitar la página, el título se muestra brevemente como "Títulos / signo numérico no admitidos", que luego fue reemplazado por un solo carácter "#". - Red rose64 🌹 ( charla ) 09:00, 21 de febrero de 2021 (UTC)
    Sí, es wikt: MediaWiki: UnsupportedTitles.js , que tiene una lista central de títulos. El problema es que intentar vincular directamente a los títulos mostrados no funcionará. - Yair rand ( conversación ) 11:54, 2 de marzo de 2021 (UTC)
  • Soporte ya que hay muchos títulos que deberían tener corchetes [] pero no pueden. # también es un problema. Pero quizás esto se podría hacer con un mecanismo para DISPLAYTITLE que permitiera verificar el abuso. Un filtro de edición podría buscar errores si se establece un estándar para mapear el nombre. Tenga en cuenta que existen otros caracteres Unicode que son similares en apariencia a los prohibidos. Graeme Bartlett ( charla ) 22:47, 24 de febrero de 2021 (UTC)
  • No por todos los puntos planteados por Izno Sea Ane ( charla ) 21:46, 26 de febrero de 2021 (UTC).
  • Oponerse a menos que el título de la página real también se muestre de forma destacada. - Kusma ( t · c ) 11:39, 2 de marzo de 2021 (UTC)
  • No , según Xaosflux e Izno. Muchos posibles dolores de cabeza por muy poco beneficio. ƒirefly ( t · c ) 13:33, 2 de marzo de 2021 (UTC)

RFC: Convención de nomenclatura de parámetros de estilo de citas 1 [ editar ]

¿Deberían eliminarse por completo los parámetros sin guiones de la familia de plantillas CS1 / 2? Primefac ( charla ) 02:14, 10 de febrero de 2021 (UTC)

Antecedentes (CS1) [ editar ]

En 2014, una RFC determinó que todos los nombres de parámetros en las plantillas de Estilo de cita 1 deben tener un alias en minúsculas que tenga separaciones con guiones entre palabras en inglés, entre (no dentro) acrónimos o entre palabras y acrónimos en inglés. La documentación debe mostrar esta versión en minúsculas y con guiones como la de "uso normal". Esto significaba, por ejemplo, que se mostraría como el parámetro preferido, mientras que se mostraba como aceptable pero no recomendado para su uso. En los años siguientes, ha habido varias tendencias y discusiones que desaprueban formalmente muchos de los parámetros sin guiones, desde un pequeño puñado ( ejemplo de 2019 ) hasta la lista actual.|access-date=|accessdate=que contiene más de 70 entradas. Muchas de estas son variantes sin guiones de las versiones preferidas / con guiones, que se están eliminando para disminuir la carga de mantenimiento y aumentar la uniformidad entre plantillas (es decir, "facilidad de uso"). Otros cambios han incluido que RefToolbar proporcione los parámetros con guiones y establezca los genfixes de AWB para reemplazar algunos parámetros .

En octubre de 2020, todos los parámetros sin guiones se agregaron a la "lista actual" vinculada anteriormente. En noviembre de 2020, se envió una solicitud de bot (" Monkbot 18 ") para eliminar o reemplazar estos parámetros obsoletos para que pudieran eliminarse del módulo base y simplificar aún más el código de la plantilla. Si bien reconoce que esta tarea era en gran parte de naturaleza cosmética , BAG y otros lugares (principalmente plantillas para la discusión ) históricamente se han alineado con la idea de una "carga de mantenimiento" como una razón válida para ediciones como estas; ver, por ejemplo, Monkbot 17 , que reemplazó (cosméticamente) un parámetro por un valor con mejor nombre para facilitar su uso.

El problema de Monkbot 18 surge del número de ediciones que se le solicitó o se le pidió que hiciera; una estimación conservadora situaría el número de ediciones que ha realizado para esta tarea durante un período de dos meses (noviembre de 2020-enero de 2021) en alrededor de 1 millón de ediciones; como se discutió en la página de discusión de la tarea , esto esencialmente ha eliminado todos menos cinco de los parámetros no separados por guiones, pero aún se requerirán otras 2-3 millones de ediciones que requieren hasta cuatro meses adicionales para "borrar" completamente estos parámetros. Además, los que se oponían al bot también expresaron su preocupación de que las discusiones a relativamente pequeña escala para desaprobar estos parámetros no habían llegado a una audiencia lo suficientemente amplia como para merecer lo que sentían eran cambios radicales.

Propuesta (CS1) [ editar ]

Hay tres opciones principales con respecto a la familia de plantillas CS1 / 2 y, por extensión, la tarea de Monkbot 18.

  • Opción A : Los parámetros sin guiones deben dejar de utilizarse y eliminarse; el bot es libre de continuar su trabajo.
  • Opción B ("statu quo"): Los parámetros sin guiones están formalmente en desuso, pero no deben eliminarse de inmediato. La desactivación se puede agrupar en genfixes o realizarse junto con otros cambios no cosméticos, pero (ignorando un posible Día del bot cosmético ) no debe realizarse por sí solo por un bot.
  • Opción C : los parámetros sin guiones no deben dejar de utilizarse; la desaprobación no debe continuar y la aprobación del bot debe revocarse. Esto también significará que la lista de parámetros obsoletos deberá actualizarse para eliminar los parámetros sin guiones.

Tenga en cuenta que esta discusión trata principalmente sobre los parámetros de la plantilla CS1 / 2 y si se deben mantener / mantener dos conjuntos completos de parámetros. No es el lugar para volver a litigar las diversas discusiones sobre la tarea de Monkbot 18; La opción B se proporciona para aquellos que sienten que la tarea no debería continuar.

Encuesta (CS1) [ editar ]

  • La primera opción A , la segunda opción B . Me alegraría ver que los genfixes de AWB asumen parte de esta carga, y me alegraría ver que esto suceda un poco más lentamente, pero debería suceder, aunque ocasionalmente es un inconveniente para mí. Además, cuando cualquier parámetro individual alcanza un estado suficientemente pequeño (por ejemplo, potencialmente todavía miles de usos, pero no cientos de miles de artículos), la plantilla debe actualizarse para no permitir ese parámetro en particular (no simplemente desaconsejarlo en la documentación), para que no sigan volviendo a entrar, porque, bueno, todavía funciona, así que ¿por qué debería molestarme? WhatamIdoing ( charla ) 19:12, 10 de febrero de 2021 (UTC)
    @ WhatamIdoing : los genfixes de AWB ya manejan esto a través de WP: AWB / RTP , por lo que las ediciones manuales y otros bots pueden ayudar a reducir la lista mientras se realizan otras ediciones (no cosméticas). GoingBatty ( hablar ) 04:12, 11 de febrero de 2021 (UTC)
    GoingBatty , ¿estás seguro de que |accessdate=será reemplazado por |access-date=editores que usen la versión actual de WP: AWB / RTP ? Creo que fue eliminado. - Jonesey95 ( charla ) 04:33, 11 de febrero de 2021 (UTC)
    @ Jonesey95 : ¡ Tienes razón! Si bien la funcionalidad existe (y otros parámetros aún se reemplazan), los editores han eliminado algunas reglas de reemplazo de partición. GoingBatty ( hablar ) 04:59, 11 de febrero de 2021 (UTC)
  • Opción A . Apoyo completar el movimiento casi terminado para alejarse de los parámetros de varias palabras sin guiones. Vea más abajo para más detalles sobre este proceso, que está siendo cuestionado ahora por muy pocos editores después de siete años de trabajo, y cuando está completado en más del 90%. Con cualquier otra plantilla, habría sido el trabajo de unos días estandarizar un estilo de nombre de parámetro y convertir todas las transclusiones. La única razón por la que el proceso para las plantillas CS1 / CS2 es diferente es que hay millones de transclusiones en lugar de cientos. - Jonesey95 ( charla ) 04:33, 11 de febrero de 2021 (UTC)
  • Opción C . Esto es inútil hacer el trabajo; ver comentario extendido en la sección de discusión. Espresso Addict ( charla ) 07:08, 11 de febrero de 2021 (UTC)
  • Opción C Si solo se limitara a unos pocos miles de páginas, no sería gran cosa. Pero cuando tiene más de 3 millones de páginas, tal vez debería ser al revés, es decir, sin guiones. Muchos bots inútiles se atascan al pasar por millones de páginas para un cambio trivial. Lugnuts Fire Walk with Me 08:20, 11 de febrero de 2021 (UTC)
  • B si no C Según los comentarios anteriores; muchos editores están claramente muy contentos con las formas sin guiones, así que ¿por qué no permitir ambas? Cambiar no tiene sentido. Muchas otras plantillas permiten alias como nombres de parámetros. No veo el problema. Pero estamos donde estamos, así que prefiero a B en lugar de C. Peter coxhead ( charla ) 09:04, 11 de febrero de 2021 (UTC)
  • Opción A (segunda opción B ), según Jonesey95. Simplifiquemos todo, como debería ser. Sube y termina el trabajo. - NSH001 ( conversación ) 10:18, 11 de febrero de 2021 (UTC)
  • Opción C . Es un ejercicio totalmente inútil. Los sin guion son mejores en mi opinión, ya que no se ajustan a la ventana de edición y pueden estar subrayados como un error tipográfico, por lo que son claramente visibles en la ventana de edición. Keith D ( charla ) 13:01, 11 de febrero de 2021 (UTC)
  • C (primera opción) o B (segunda opción). He leído muchas de las discusiones sobre este tema y nunca he visto nada que me convenza de que la desaprobación en realidad beneficia a la enciclopedia de alguna manera. Incluso si asumimos por el mismo argumento que de alguna manera lo hace, la interrupción real y evidente causada por el bot hasta ahora y el alcance de los cambios que el operador del bot observe serán necesarios para completar la tarea, muy clara y significativamente superan eso beneficio. Thryduulf ( conversación ) 15:20, 11 de febrero de 2021 (UTC)
  • Opción A: este cambio es un poco doloroso, pero es mejor para editar a largo plazo. Es mejor hacer este cambio que no hacerlo. El mejor momento habría sido hace quince años, pero el segundo mejor es ahora. Permita que el bot continúe su operación, elimine todos los parámetros y, una vez que se eliminen todos, comience a generar errores de citación. Elliot321 ( discusión | contribuciones ) 17:09, 11 de febrero de 2021 (UTC)
  • Opción A . Desafortunadamente, el editor visual existe ... pero no es útil para proyectos de edición grandes y, por lo tanto, muchas personas todavía usan la edición de wikitexto; la condensación en un formulario (específicamente el con guión, ya que es más fácil de leer para los editores) ayudará a garantizar la coherencia entre artículos al menos en las plantillas CS1. Obviamente, esto no hará que cada artículo más fácil de editar, ya que hay artículos con citas de estilo no CS1, sino que va a ayudar a los millones de personas que hacen uso de CS1 se ve igual a los editores en vez de tener una mezcolanza de nombres con guiones. Además, estoy de acuerdo con que el bot continúe ejecutándose ahora, y luego se ejecute tal vez una vez por semana más o menos después de esta ejecución inicial para corregir cualquier nombre de parámetro sin guiones de CS1. -bɜ: ʳkənhɪmez ( Usuario / saluda!) 17:13, 11 de febrero de 2021 (UTC)
  • Opción C. El objetivo de las plantillas y los bots es que deben trabajar para facilitar la vida de los editores, no que los editores deban cambiar la forma en que hacen las cosas para facilitar la vida de los creadores de plantillas y bots. Este bot lo tiene completamente al revés, y si el grupo de aprobaciones de bots lo ha aprobado, entonces eso es un problema con ese grupo, no con algunos parámetros sin guiones. No puedo evitar sentir que ese grupo está mirando los intereses de algunos operadores de bots en lugar de los muchos más editores y aún muchos más lectores. No hay una gran complejidad en tener algunos sinónimos para los parámetros de la plantilla, y no hay ningún problema con la exportación de datos: si los parámetros sinonímicos apuntan al mismo lugar en el código, entonces se pueden exportar en el mismo formato sin esfuerzo adicional. Puedo'No creo que cuarenta años después de que entré en TI todavía esperamos que los usuarios sean esclavos de los sistemas que se supone que los ayudarán.Phil Bridger ( charla ) 18:21, 11 de febrero de 2021 (UTC)
    El objetivo de las plantillas y los bots es que deberían funcionar para facilitar la vida de los editores.. Exacto así. Para eso es este bot. Hace que los nombres de los parámetros sean más fáciles de leer (tomándolos como un todo, no solo la fecha de acceso por sí sola), reduce el tamaño de la documentación de la plantilla, hace que los nombres de los parámetros sean todos coherentes. Todos estos se combinan para facilitar el aprendizaje de cómo usar las plantillas de citas. También facilita el mantenimiento de las plantillas. una situación de ganar-ganar. La única razón por la que estamos teniendo esta discusión es que el software de listas de seguimiento de Mediawiki es tan malo en el manejo de ediciones de bots. De lo contrario, sería una obviedad. Algunas personas aquí parecen estar bajo el temor erróneo de que esto es solo para promover los intereses de "algunos operadores de bots". Bueno, estoy bastante seguro de que Trappist (el operador de este bot) podría prescindir del estrés de planificar, escribir y ejecutar este bot. Él hace un trabajo fantásticoy merece un gran reconocimiento y reconocimiento por su trabajo.No puedo creer que cuarenta años después de que entré en TI todavía esperamos que los usuarios sean esclavos de los sistemas que se supone que los ayudarán. El motivo de este bot es facilitar la vida de los usuarios. FWIW, también tengo experiencia en el trabajo de TI hace más de 40 años (en comisión de servicio durante 2 años para trabajar en un proyecto (muy exitoso): programación matemática en big data para una compañía de seguros de vida) y, desde entonces, tuve que relacionarme con personas de TI con frecuencia . Soy muy consciente de los problemas que pueden surgir cuando simplemente permite que los sistemas se vuelvan cada vez más complejos, por lo que aprecio los esfuerzos de Trappist (y de muchas otras personas) para simplificar las cosas. - NSH001 ( conversación ) 23:37, 11 de febrero de 2021 (UTC)
    Aclarando: Releyendo esto de nuevo esta mañana, a los lectores que no lean con atención les puede parecer que estoy de acuerdo con Phil Bridger. Nada podría estar más lejos de la verdad, todavía apoyo a la Opción A . La opción C no tiene sentido, por todas las razones establecidas por SMcCandlish. - NSH001 ( conversación ) 08:35, 12 de febrero de 2021 (UTC)
    Y la hipérbole de Phil Bridger es falaz. La opción B no impone nada a nadie. "No me gusta la opción A" no equivale a "solo la opción C puede funcionar". La opción B es el statu quo y no ha roto nada. Estoy bastante sorprendido de lo obvio que es esto, pero al menos 10 editores no parecen haberse dado cuenta. Sé que hay mucho populismo en el mundo, mucho "Me sentiría muy convencido de esto, si fuera cierto, y se siente bien fingir que es verdad, así que voy a fingir que es verdad " comportamiento. Pero esas cosas deben dejarse en la puerta.  -  SMcCandlish ☏ ¢  😼  04:21, 12 de febrero de 2021 (UTC)
    No, mi postura no es una hipérbole ni se debe al populismo. La razón por la que rechazo la opción B es la palabra "inmediatamente". Todavía deja el consenso actual de que las versiones sin guiones de los parámetros se eliminarán, pero no de inmediato, y es ese consenso el que debería cambiar, por muchos años que haya permanecido estable. Estoy contento con la simplificación de la documentación, pero no con la eliminación de la opción. Phil Bridger ( charla ) 09:19, 12 de febrero de 2021 (UTC)
    Como se señaló anteriormente: la obsolescencia no es sinónimo de deshabilitar. Está confundiendo el reemplazo de los parámetros tal como están escritos en una plantilla transcluida en una página, con la eliminación de la capacidad de la variante del parámetro runtogether para funcionar en la plantilla. La única opción A haría lo último. Tenemos muchas, muchas plantillas que admiten parámetros de ortografía variante pero no los "anuncian" en la documentación, y no rompe nada en absoluto reemplazarlos por bot con la versión canónica, al igual que el mismo bot reemplazará las llamadas a un nombre de redireccionamiento. para la plantilla con el nombre de página real de la plantilla. Es decir, estás teniendo una fuerte reacción negativa a un argumento que la opción B en realidad no está haciendo .  -  SMcCandlish ☏ ¢  😼  17:50, 13 de febrero de 2021 (UTC)
    La opción B dice claramente "pero no debe eliminarse de inmediato". O la palabra "inmediatamente" tiene algún significado y esta opción conduciría a la eliminación, pero no inmediatamente, o no tiene significado y no tiene por qué estar allí. Phil Bridger ( charla ) 18:10, 13 de febrero de 2021 (UTC)
    SMcCandlish , esto se explicó en la discusión anterior en CS1: "" Desactivación ", según la definición utilizada en el contexto de CS1 / CS2, significa que si se utiliza el parámetro, se mostrará un mensaje de mantenimiento rojo y aparecerá en una categoría de seguimiento. Es una fase antes de la eliminación del soporte para un parámetro (en cuyo caso solo se mostrará un mensaje de "parámetro no admitido" y, opcionalmente, una pista sobre el nuevo parámetro). Es posible permanecer en este estado durante períodos de tiempo prolongados, pero la idea es que eventualmente la funcionalidad Vamos". Entonces, la intención es cometer errores y luego eliminar la funcionalidad de estos parámetros, no simplemente no anunciarlos en la documentación. Si desea proponer una variante de la opción C que elimina los parámetros de la documentación pero aún les permite funcionar, adelante, pero la opción B no es eso.Nikkimaria ( hablar) 20:09, 13 de febrero de 2021 (UTC)
    Lo que quiero proponer es una variante de la Opción B que elimina los parámetros de la documentación antes de dejar que algún bot cambie los artículos de mi lista de seguimiento como si los parámetros fueran de alguna manera malos. Si los parámetros son realmente malos, y si hay un consenso al respecto , entonces el primer paso es eliminarlos de la documentación (ya sea arrastrándolos en la oscuridad de la noche, en silencio, como ninjas, o mencionándolos de manera transparente como desaprobado, para que todo el mundo sepa lo que está pasando). La primera fase de la desaprobación real es decirle a la gente que deje de usar algo. Entonces puedes empezar a lanzar mensajes rojos y no es tan malditamente grosero o sorprendente. -  JohnFromPinckney (hablar ) 21:40, 13 de febrero de 2021 (UTC)
    Claro, yo también apoyaría esa variante. O una variante que mantenía la mención de esas versiones de los parámetros pero las desaprobaba. Lo que sea que nos acerque a tener coherencia en las plantillas implementadas reales que se utilizan en las citas.  -  SMcCandlish ☏ ¢  😼  04:15, 14 de febrero de 2021 (UTC)
    Estas cosas deberían estar en una categoría de seguimiento, si eso es con lo que van a trabajar los bots y otras herramientas. Si no nos gustan los mensajes de error, podemos desactivarlos. Esto es solo una plantilla y un código de módulo, no está grabado para siempre en la cara de una montaña como el monte. Rushmore.  -  SMcCandlish ☏ ¢  😼  04:15, 14 de febrero de 2021 (UTC)
  • Opción C Estoy totalmente de acuerdo con Phil Bridger aquí. En otras palabras, no veo qué se logra exactamente al hacer millones de ediciones cosméticas y luego romper deliberadamente cosas que de otro modo hubieran funcionado. * Pppery * ha comenzado ... 20:21, 11 de febrero de 2021 (UTC)
    La opción B no rompe nada. Usted, et al., Está proporcionando un argumento en contra de la opción A, no un argumento real para C, y simplemente ignora B. Además, un! Voto por C es un! Voto para anular un status quo que ha sido estable durante años , en favor del caos, pero sin una justificación real para hacerlo. El vendedor debe tener eso en cuenta, según WP: NOTAVOTE . En el caso de un resultado "sin consenso", todavía terminamos con el statu quo. Cosas como esta son la razón por la que sigo diciéndole a la gente que necesitan escribir mejor las RFC. "Todo lo que pueda malinterpretarse lo será".  -  SMcCandlish ☏ ¢  😼  04:21, 12 de febrero de 2021 (UTC)
    SMcCandlish , la opción B admite la desactivación de los parámetros no separados por guiones, que es un cambio importante. La diferencia entre A y B es la velocidad, no el resultado. Su! Voto a continuación sugiere que desea que las variantes sin guiones sigan siendo compatibles, pero de las opciones proporcionadas, solo la opción C lo logra. Nikkimaria ( charla ) 16:18, 13 de febrero de 2021 (UTC)
    No. Vea mi respuesta a la misma afirmación de Phil Bridger, más arriba.  -  SMcCandlish ☏ ¢  😼  17:50, 13 de febrero de 2021 (UTC)
    Sí, ver arriba. También puede ver lo que ha sucedido con los parámetros de CS1 anteriormente obsoletos, como |authorfirst=: no funcionan. Nikkimaria ( charla ) 20:09, 13 de febrero de 2021 (UTC)
    Lo cual está perfectamente bien, dado el tiempo suficiente para que la gente deje de usarlos. Por lo tanto, elimínelos de la documentación de la plantilla y reemplácelos en las translcusiones de plantillas implementadas. Eventualmente, el efecto de "mono ve, mono hace" de estar expuesto a variantes de parámetros en desuso desaparece, a través de una exposición disminuida y eventualmente cero. Soy malo, vamos, eso es lo que el punto de desaprobación es . Me parece que usted [plural] viene de una perspectiva de "dame C o dame la muerte", combinando artificialmente A y B porque simplemente no tolerarás la idea de que ninguna variante de nombre de parámetro desaparezca por ningún motivo. Si me equivoco acerca de esa percepción, por favor explique.  -  SMcCandlish ☏ ¢  😼  04:18,14 de febrero de 2021 (UTC)
  • Opción C por Phil Bridger. Ealdgyth ( charla ) 21:28, 11 de febrero de 2021 (UTC)
  • Opción C : comentar aquí probablemente se incluye en la lista de mis médicos de "cosas que HF no debería hacer mientras tiene una conmoción cerebral", pero no quiero perderme esta discusión. Si bien entiendo que mantener las plantillas de citas no es un trabajo particularmente fácil, al final, la rigidez en la plantilla de citas no es deseable. Las plantillas de citas deben ser fáciles de usar y tener un par de alias para los parámetros más comunes facilita su uso. Y un truco para el gremio de bots por aprobar una tarea de bot que fue diseñada para desaprobar los parámetros de la plantilla sin consenso para esa desaprobación. Charla sobre la granja de cerdos 22:15, 11 de febrero de 2021 (UTC)
  • La primera opción A , la segunda opción B . El texto fuente de Wikipedia se está volviendo cada vez más complejo y difícil de administrar, lo que lo hace menos accesible, excepto por el tipo de editores experimentados que participan aquí. Cualquier cosa que podamos hacer para reducir la complejidad es una ganancia, menos opciones mejor cuando es simplemente redundante. - Green C 22:41, 11 de febrero de 2021 (UTC)
  • Opción C según Phil Bridger, personalmente prefiero los parámetros sin guiones, y considero que desaprobarlos es un ejercicio absolutamente inútil que rompe las cosas sin ninguna otra razón que satisfacer las preferencias cosméticas de algunos editores. Devonian Wombat ( charla ) 00:14, 12 de febrero de 2021 (UTC)
  • Opción C . En gran parte por granja de cerdos. Mantener los alias de uso muy común es útil para los editores que utilizan estas plantillas. Nikkimaria ( charla ) 01:17, 12 de febrero de 2021 (UTC)
  • Apoyo a la opción C, neutral en la opción B, se oponen fuertemente la opción A . Mis dedos están acostumbrados a escribir muchos de estos nombres de parámetros sin guiones. Dejarlos en desuso y el gnome trabajo que los acompaña de reemplazarlos con las versiones no obsoletas ya me está causando una molestia significativa, tanto al tratar de recordar que realmente ahora deberían estar divididos con guiones, como al tratar de seleccionar los cambios importantes en mi lista de observación entre todos los gnomery inútil. Eliminar las formas sin guiones por completo sería peor. - David Eppstein ( charla ) 01:41, 12 de febrero de 2021 (UTC)
  • Opción C . Estoy con Phil Bridger y Hog Farm. No sé si se trata de deshacerse de la bicicleta o de afeitarse el yak, pero no es productivo y tiene mal aspecto. Las alternativas existen porque es más simple que recordar cuál de dos posibilidades comunes es aceptable, en lugar de forzar una u otra (como hacen las otras opciones). Por otro lado, discutir la eficiencia debido a un carácter fuera de la fila (¿oh, entonces estamos tomando esta decisión en función de que todos usen QWERTY?) Es el tipo de razonamiento de ignorar hechos prácticos que produce resultados finales en forma de ornitorrinco. - Mikeblas ( charla ) 01:52, 12 de febrero de 2021 (UTC)
  • A es mejor a largo plazo, pero B por ahora, y la conversión está cubierta por genfixes de AWB y similares. Headbomb { t · c · p · b } 02:29, 12 de febrero de 2021 (UTC)
    Comentario Desafortunadamente, en este caso, dejarlo solo a los genfixes de AWB no sería efectivo ni deseable. Debido a que es probable que haya tantos de estos parámetros en una página determinada, es probable que los genfixes inunden el cambio principal previsto, causando una molestia comprensible. Es mucho mejor dejarlo en manos de este excelente bot, que es claro y abierto sobre lo que está haciendo, sin sorpresas desagradables. Es por eso que prefiero la opción A a la opción B, pero cualquiera de estas es muy preferible a la opción C. - NSH001 ( hablar ) 08:31, 7 de marzo de 2021 (UTC)
  • Opción C por Phil Bridger. SarahSV (charla) 02:51, 12 de febrero de 2021 (UTC)
  • Opción C . Este enfoque de "todo debe estar dividido con guiones" no funciona bien con el editor de texto. Para algunos parámetros comunes como |accessdate=, es simplemente mejor sin guiones porque el texto de origen es más rápido y más fácil de analizar para un humano porque el parámetro no se ajusta con palabras en el cuadro de texto del editor. Jason Quinn ( charla ) 03:09, 12 de febrero de 2021 (UTC)
  • Opción B . Deberíamos dejar de enumerar los que no tienen guiones en la documentación al menos, de modo que entre el cambio editorial y la limpieza de AWB / bot genfixes, seamos más consistentes con el tiempo. Es demasiado pronto para la opción A, si alguna vez, porque las plantillas nos sirven, no servimos las plantillas. Está perfectamente bien que las plantillas admitan silenciosamente variantes sin guiones para que no se rompan si la gente las prueba. Pero no deberíamos seguir enumerando esas variantes en los documentos. Es contrario al propósito de las plantillas, para nosotros perpetuar la inconsistencia (sin una buena razón, como un ENGVAR color vs. colordistinción). Y sin sentido hace que la documentación sea más larga y compleja sin ningún beneficio; nadie que busque cómo especificar la URL de Archive.org necesita saber nada más |archive-date=, y decirles que |archivedate=también funciona es simplemente meterse trivialidades sin sentido en la cabeza. Sí, continúe convirtiendo a versiones con guiones en genfixes y otras ediciones automatizadas (cuando haga algo más sustantivo al mismo tiempo). Finalmente, la opción C es bastante inútil. Regularmente hemos estado desaprobando (gradualmente) varios nombres de parámetros antiguos, y ha funcionado muy bien. La opción B no romperá nada y tendrá (ya está teniendo) resultados positivos.  -  SMcCandlish ☏ ¢  😼  04:21, 12 de febrero de 2021 (UTC)
  • Opción B Opción C . Todos estos son alias válidos, ya que no hay confusión entre say|access-date=y|accessdate=. El status quo funciona bien: se prefiere el uso de guiones porque es más fácil de leer, pero sin guiones es aceptable porque no hay ambigüedad y, evidentemente, mucha gente lo escribe de esa manera. Los cambios cosméticos deben cumplir con la política. -  Finnusertop ( talk ⋅ contribs ) 05:53, 12 de febrero de 2021 (UTC) Cambiado de B a C porque me opongo a las implicaciones de la parte "formalmente obsoleta" de estos alias válidos. -  Finnusertop ( charla ⋅ contribuciones ) 09:26, 12 de febrero de 2021 (UTC)
  • Opción C primera opción (B segunda). Los editores deben poder utilizar versiones con guiones o sin guiones. La consistencia no es mejor que la flexibilidad aquí: las únicas personas que leen el parámetro son los editores, así que deje que los editores decidan si quieren o no usar un guión en los parámetros de su plantilla. Comparto la preocupación general sobre la desconexión entre los escritores de código y los escritores de contenido, y la frustración con algunos mantenedores de plantillas y bots que imponen decisiones a todos sin consenso. La edición de hechos consumados en millones de ediciones o transclusiones es algo muy importante. Levivich  acoso / sabueso 07:20, 12 de febrero de 2021 (UTC)
  • Me gusta C : me hago eco especialmente de los comentarios de Levivich, Thryduulf | y Phil Bridger sobre estas nuevas y perennes sorpresas periódicas en lo que respecta a la edición de artículos. Eso es perturbador y simplemente deberíamos detenerlo. C, por lo tanto, devolverá la cordura. G en Q uest "scribble" 07:42, 12 de febrero de 2021 (UTC)
  • Opción C . Estas son plantillas para que las usen los editores, no tienen ningún impacto en los lectores y es una completa pérdida de tiempo crear reglas y regulaciones sobre ellas y luego escribir bots para hacer cumplir esas reglas inútiles. Sin mencionar que cuando AWB pasa por "arreglar" todo esto en un artículo, puede ahogar las ediciones genuinas y hacer que sea más difícil para las personas rastrear lo que está sucediendo. Deshazte de esta ridícula regla, bórrala de AWB, y luego tal vez podamos seguir construyendo una enciclopedia. -  Amakuru ( charla ) 09:13, 12 de febrero de 2021 (UTC)
  • Opción C (que es el statu quo ante ). Simplemente no veo qué problema está tratando de solucionar la gente, así que siga WP: NBDF . Los parámetros con guiones son útiles y mejoran la legibilidad del wikitext, personalmente los prefiero, pero permitir ambas formas facilita las cosas a los editores. Desaprobarlos parece inútil y eliminarlos por completo parece activamente dañino. Ha creado millones de ediciones inútiles y ocupadas que obstruyen las listas de seguimiento sin una buena razón. No tenemos ningún problema con los alias de las plantillas, entonces, ¿por qué preocuparse por los alias de los parámetros? Ninguno ha sido articulado de manera convincente. Modest Genius talk 12:10, 12 de febrero de 2021 (UTC)
  • Desde que me hicieron ping, neutral en todos los sentidos. Siento nostalgia por el status quo por algunas razones ya presentadas (memoria muscular, saltos de línea), pero reconozco que una vez que pasemos por el valle de la sombra y salgamos a las tierras altas brillantes de una implementación más limpia, han olvidado el dolor. Eso sí, probablemente tenga 90 años y no me importe. Pero tengo algunas inquietudes sobre la implementación en la Discusión. David Brooks ( charla ) 16:54, 12 de febrero de 2021 (UTC)
  • Opción C : la estandarización de este tipo puede ser útil para los investigadores o desarrolladores, pero no para los usuarios habituales. Agregar citas debería ser lo más fácil posible. Con ese fin, quiero minimizar las posibilidades de que la interfaz no sepa lo que estoy tratando de hacer, o de que obtenga un error porque ingresé un guión bajo en lugar de un guión. El resto de Internet está tratando de aumentar la flexibilidad para que la experiencia del usuario sea fácil e intuitiva. También lo hacemos de muchas formas. Pero aquí parece que estamos haciendo lo contrario: eliminando la flexibilidad y exigiendo a los usuarios que sepan cómo hemos redactado / organizado las cosas.
    No me importa si hay un bot que los estandariza después o si alguien ejecuta AWB detrás de mí. Una vez más, obtengo el atractivo de la estandarización. Deberíamos hacer todo lo posible para que la experiencia sea intuitiva para los usuarios habituales. - Hablar de las rododendritas \\ 23:04, 12 de febrero de 2021 (UTC)
    • Alternativa: Opción D : deje que el bot y / o AWB estandaricen, pero nunca deshabilite los parámetros. La estandarización es buena; la usabilidad degradante es mala. - Hablar de las rododendritas \\ 23:12, 12 de febrero de 2021 (UTC)
      Ciertamente apoyaría su opción D si estuviera sobre la mesa, pero no puedo admitir nada que diga que esta funcionalidad debe eliminarse, ya que la opción B (a pesar de las afirmaciones analfabetas anteriores de que no lo hace) exige claramente. Phil Bridger ( charla ) 18:10, 13 de febrero de 2021 (UTC)
  • Opción A con B como mi segunda opción. Mantener nuestras complejas plantillas de citas no es una tarea fácil, y si las personas que están trabajando quieren hacer esto para facilitar su trabajo, estoy a favor de ello. Legoktm ( charla ) 23:48, 12 de febrero de 2021 (UTC)
  • Opción C con la opción B como segunda opción: Modest Genius hace un comentario excelente, al igual que varios otros. La comunidad debe dejar de perder su tiempo en estas tonterías de formato de citas y hacer el trabajo duro de introducir citas en artículos en su lugar, donde en realidad tenemos una crisis desesperada frontal que daña nuestra reputación. yo suelo|accessdate=y no tengo intención de parar. Recuerdo muy claramente el proceso por el que pasé para aprender las plantillas de citas en 2014; al principio eran confusas, pero nunca tuve una sola confusión al analizar "fecha de acceso" como la frase de dos palabras "fecha de acceso", lo que significa muy claramente la fecha de la última accedió a una referencia. Puedo ver que, en teoría, esto sería un poco mejor para los nuevos usuarios, y puedo ver que, en la práctica, algunas personas a las que no les gusta el aspecto de "fecha de acceso" lo están escalando ("mi opinión" se convierte en "la vista correcta" se convierte en "un imperativo moral para hacer cumplir"), pero esto simplemente no supera el dolor genuino real que hará que los editores como yo reentrenan una memoria muscular desarrollada durante años;Casi todas las ediciones del espacio principal que hago durante meses tendrán un flujo interrumpido (interrumpe mi proceso de pensamiento, pierde el tiempo escribiendo de nuevo) si esto va a cambiar.
    En cuanto al bot que ha estado perdiendo varios minutos de mi tiempo al día, me opuse firmemente en primer lugar y he tenido más que suficiente. (No, no puedo ignorarlo, porque si desactivo las ediciones de bots, me perderé los actos de vandalismo, cambios no constructivos o etiquetado de limpieza que están ocultos por una edición de bot posterior). Los BRFA necesitan publicidad más amplia cuando su alcance es tan enorme y su violación de WP: COSMETICBOT tan abierta. No acepto que la opción B refleje el consenso pasado en la práctica en el sentido de que no recuerdo que nadie se haya acercado a mí acerca de mi uso |accessdate=o cambio |access-date=manual. El consenso local pasado entre los grupos técnicos que no trabajan en el espacio de artículos, seguro. ¿Pero el consenso de la comunidad enwiki? No. - Bilorv ( hablar) 01:07, 13 de febrero de 2021 (UTC)
    • @ Bilorv : si desactivo las ediciones del bot, me perderé los actos de vandalismo, cambios no constructivos o etiquetado de limpieza que están ocultos por una edición posterior del bot ; esto siempre me sorprende. Solo por curiosidad, pero ¿por qué no habilitar la opción "Expandir lista de seguimiento para mostrar todos los cambios, no solo los cambios más recientes" + "Agrupar los cambios por página en los cambios recientes y la configuración de la lista de seguimiento"? No veo ediciones de bots y no cubren nada. - Hablar de las rododendritas \\ 02:50, 13 de febrero de 2021 (UTC)
      • @ Rododendritas : ¡ agradezco la sugerencia! Nunca se me ocurrió que combinarlos produciría esa funcionalidad (hay tantas combinaciones complejas de filtros de lista de observación y opciones de preferencias), pero habilité esos dos y mantuve la "Última revisión" activada y habilité "Humano (no bot)". ya que la opción de preferencia "Ocultar las ediciones de bot de la lista de seguimiento" no parecía hacer eso y ahora creo que (tamaño de muestra pequeño en el cajero automático de mi lista de seguimiento) veo solo el último cambio, incluso si es un bot, pero solo si al menos se ha realizado una edición que no es un bot (que es exactamente deseable). - Bilorv ( conversación ) 11:34, 13 de febrero de 2021 (UTC)
  • Opción A con B como mi segunda opción. Mantener las complejas plantillas de citas no es una tarea fácil. AManWithNoPlan ( hablar ) 02:52, 13 de febrero de 2021 (UTC)
  • Opción A sobre la base de que la estandarización es buena. En realidad, no me importa si los guiones están ahí o no, pero es mejor de una forma u otra en lugar de tener una mezcla. En general, prefiero que abandonemos el uso de wikitext como información de referencia, aunque es como hacer sus finanzas en un documento de texto. Gracias. Mike Peel ( charla ) 18:26, 13 de febrero de 2021 (UTC)
  • Opción A Siempre he preferido personalmente el formulario con guión porque permitía al corrector ortográfico verificar que no había errores tipográficos, mientras que el formulario sin guiones siempre se marca como un error tipográfico, aunque la vista previa ahora me informa de los errores. No estoy de acuerdo con la afirmación de que los humanos pueden analizar |accessdate=más rápidamente que |access-date=; los espacios fueron inventados por esta razón. También conozco la sobrecarga que implica permitir múltiples parámetros que significan lo mismo en las plantillas. Soy consciente de que esto ha estado saturando mi lista de seguimiento con ediciones de Monkbot, pero mi voto es continuar. Hawkeye7 (discutir) 22:12, 13 de febrero de 2021 (UTC)
    Tenga en cuenta que esto es principalmente un razonamiento de WP: ILIKEIT y descarta las opiniones de aquellos que indican que pueden analizar la "fecha de acceso" sin problemas como incorrectos sin ninguna evidencia. También descarta la interrupción muy real causada a otros como necesaria para reducir los gastos generales, mientras que esta sobrecarga, incluso si es significativa como algunos afirman (para la cual nunca se ha presentado evidencia convincente) sigue siendo trivial en comparación con la interrupción causada por Monkbot. ediciones y por la interrupción innecesaria a los editores que utilizan las plantillas. Thryduulf ( conversación ) 15:29, 14 de febrero de 2021 (UTC)
  • B o C . No tengo una gran preferencia entre la fecha de acceso o la fecha de acceso, ambas parecen utilizables, si se prefiere formalmente una, entonces está bien. Sin embargo, el spam de bots en curso masivo para algo que literalmente no tiene ningún efecto en los lectores, y apenas en los editores, no está justificado. Además de estar en todas partes en la lista de seguimiento, Monkbot hace que sea mucho más difícil desenredar varias series de diferencias en el historial de edición para obtener pocos beneficios. Un usuario que realiza una edición insertando "fecha de acceso" no es un problema atroz que debería hacer que un bot se ejecute, y dicha acción del bot oculta la edición en cuestión de las listas de seguimiento. CMD ( charla ) 18:18, 14 de febrero de 2021 (UTC)
  • Opción C . La eliminación de una forma común de escribir parámetros en las plantillas reduce la facilidad de uso para los usuarios finales. Tener un bot dando vueltas y "arreglando" esto tiene un impacto negativo en la legibilidad del historial de la página y las listas de seguimiento. Nadie en esta conversación ha demostrado que la carga de mantenimiento de la plantilla sea tan importante que justifique todas estas desventajas. También parece que la carga de mantenimiento no es algo que sea difícil de rastrear, como los enlaces azules accidentales a artículos de temas principales cuando se pretendían artículos de temas no primarios, ya que el código de la plantilla está en las páginas de la plantilla .---- Patar knight - chat / contribuciones 18:53, 14 de febrero de 2021 (UTC)
  • Opción C . Las discusiones anteriores vinculadas anteriormente (un RFC de seis años con siete personas participando en él, que prometió específicamente que no se depreciaría nada, seguido de un argumento ondulado sobre la carga de mantenimiento), no son ni remotamente suficientes para justificar un cambio tan radical. Sí, la carga de mantenimiento es una molestia, pero afecta a un puñado relativamente pequeño de autores de bots; La eliminación de la versión más utilizada de un parámetro de plantilla afecta a una gran cantidad de editores, a los que se les debe dar deferencia aquí debido a que son un grupo más grande. Y, obviamente, no es noun consenso permanente de que la carga de mantenimiento justifica tales cambios (al menos no uno en una escala necesaria para justificar esto), o esta discusión no estaría tan claramente dividida. Por lo tanto, la versión sin guiones nunca debería haberse depreciado, lo que hace que las ediciones del bot sean un desorden inútil en el mejor de los casos y un intento de impulsar un cambio controvertido sin un consenso suficiente a través de fiat compli en el peor de los casos. Además, si la carga de mantenimiento es la única preocupación, obviamente la solución es revertir el RFC de 2016 (que, nuevamente, solo tenía siete personas participando y acordó simplemente crear las versiones con guiones como alternativas) y eliminar la versión con guiones , que actualmente ve poco uso y, por lo tanto, sería mucho más fácil y menos perjudicial de desechar. -Aquillion ( charla ) 22:12, 15 de febrero de 2021 (UTC)
  • Opción B -ish. Creo que es razonable que las formas divididas con guiones sean la versión canónica del parámetro, pero no veo ninguna razón para hacer ediciones masivas para cambiar de una forma a otra o para cambiar las reglas habituales sobre los bots cosméticos aquí. No veo ningún daño en la Opción C, pero la implementación de la Opción A cambiará los problemas actuales por otros nuevos. - AntiCompositeNumber ( conversación ) 02:15, 16 de febrero de 2021 (UTC)
  • Fuerte soporte A : la estandarización de los parámetros de la plantilla es importante y útil.
Leve Apoyo B : el # de |accessdate=por página es demasiado terriblemente alto (mayor parte del tiempo), hasta tal punto que interfiere con la comprobación regular de WP: GenFixes (es decir, muchas diferenciaciones de una sola pantalla se hacen diferenciaciones de pantalla muchos) - lo haría Fuerte apoyo B IIF Monkbot pudo continuar y separar con guiones al menos este parámetro.
Strong oponerse C : antítesis de A .
~  Tom.Reding ( talk ⋅ dgaf )   19:23, 16 de febrero de 2021 (UTC)
  • ¿Para quién es importante y útil la estandarización de los parámetros de la plantilla? Phil Bridger ( charla ) 20:39, 16 de febrero de 2021 (UTC)
  • ¿Cómo y por qué la estandarización es más importante y útil que los editores que pueden mejorar la enciclopedia sin necesidad de conocer el formato exacto de los nombres de los parámetros y lidiar con listas de seguimiento e historiales de páginas llenos de ediciones cosméticas? Thryduulf ( conversación ) 20:45, 16 de febrero de 2021 (UTC)
  • ¿Están sugiriendo que recuperemos todos los parámetros obsoletos y agreguemos más para que cada usuario pueda elegir usar los nombres de los parámetros que les resulten más cómodos / comprensibles / intuitivos? Estoy de acuerdo con la depreciación suave: permitir ambos, pero desalentar / convertir uno, a granel una vez a través de un bot, luego de forma gradual / pasiva a través de WP: GenFixes y otras herramientas, pero esa no es una de las opciones.
    Re: "listas de seguimiento": se puede configurar para ignorar los bots hasta que esté listo.
    Re: "historias llenas de ediciones cosméticas": el bot solo requiere 1 edición; apenas "lleno de"; Independientemente, existe un consenso de la comunidad para WP: CBD .    ~  Tom.Reding ( hablar ⋅ dgaf )   12:16, 17 de febrero de 2021 (UTC)
    Sí, sugiero que todos los parámetros de dos palabras deben aceptar variedades con guiones y sin guiones. Está bien que uno sea preferido sobre el otro en la documentación, pero ambos deberían funcionar y seguir funcionando, ya que esto es, con mucho, lo menos perjudicial para los editores y les permite dedicar su tiempo a producir / mantener contenido en lugar de preocuparse por la sintaxis meticulosa. No tengo objeciones masivamente fuertes a las correcciones generales que sustituyen una por la otra cuando realizo cambios no cosméticos en la página, pero no lo recomendaría activamente, ya que saturará las diferencias sin ningún beneficio. Me opongo firmemente a las ejecuciones masivas de bots y a hacer que una opción no sea funcional en el futuro. Thryduulf ( conversación ) 15:29, 17 de febrero de 2021 (UTC)
    Re "¿Están sugiriendo que recuperemos todos los parámetros obsoletos" ? Sí, eso es correcto. En primer lugar, nunca deberían haber quedado obsoletos. Esta es una plantilla, que se encuentra en segundo plano y existe para la conveniencia del editor, nada más. La obsolescencia de los parámetros reduce esa conveniencia. Y está bien establecido que los bots y los editores no deberían realizar cambios cosméticos en el wikitexto que no modifiquen la página, por lo que también deben detenerse. -  Amakuru ( charla ) 12:48, 18 de febrero de 2021 (UTC)
  • Opción C, supongo , ya que no me han persuadido en cuanto a la utilidad marginal de las versiones con guiones. Sin esa claridad, no deberíamos estar haciendo este tipo de cambios. (Y si nos tuvimos consenso, entonces B, pero con cambios en la documentación como el primer paso.) -  JohnFromPinckney ( talk ) 01:48, 17 de Febrero 2021 (UTC)
  • Opción C Si funciona, no lo arregle. Andrew 🐉 ( charla ) 13:01, 17 de febrero de 2021 (UTC)
  • Opción A, oponerse firmemente a la opción C: cualquiera que trabaje con regularidad en plantillas o módulos apreciará el valor de decidirse por un estilo único para cuestiones como los nombres de los parámetros. No me importa cuál sea el estilo acordado, siempre y cuando sea coherente, y el argumento sobre si debe estar dividido con guión, subrayado, camel-case o run-on se ha resuelto con guiones como estilo preferido. Entonces no tiene sentido no implementar ese estilo, y preferiría que se hiciera lo antes posible. Todo este debate recuerda las guerras de vinculación de fechas en las que se hicieron fuertes objeciones a la desvinculación de fechas, sin embargo, a los pocos meses de que se tomara una decisión vinculante para desvincular las fechas, todos habían seguido adelante y hoy nadie consideraría vincular fechas. Una vez que hemos estandarizado los parámetros con guiones,los futuros editores mirarán hacia atrás y pensarán cuán aburrido y desperdiciador de tiempo es este tipo de debate. -RexxS ( charla ) 19:46, 19 de febrero de 2021 (UTC)
  • A o B pero no C según Scott, Hawkeye y RexxS. El uso de un guión es fácil de usar, y mientras hay algo de trabajo en nuestra parte para hacer el interruptor, es mejor si tiene algún delimitador entre las palabras en lugar de ejecutarlas juntas. Al igual que dejamos de vincular fechas y ya no SmashWordsTogether , vale la pena el inconveniente temporal. - Wug · a · po · des doce y cuarenta y seis, 20 de Febrero 2021 (UTC)
    Notwhen it'sjust twowords :-P Levivich  acosar / perro 08:10, 20 de Febrero 2021 (UTC)
    ... así se vería su comentario si permitiéramos a las personas usar cualquier método que les funcionara y aún así lo hiciéramos funcionar. Si desactivamos esos parámetros, su comentario no habría aparecido. Si permitimos que las personas usen lo que sea que funcione y usen un bot para limpiarlo después, su comentario se vería como el de todos los demás después de un período de tiempo (durante el cual su comentario seguirá siendo funcional, incluso si a veces se combinan pares de palabras) . :) - Hablar de las rododendritas \\ 20:15, 22 de febrero de 2021 (UTC)
  • Opción A para todos los argumentos ya presentados extensamente en las páginas de discusión de CS1 / CS2 a lo largo de los años y los buenos argumentos presentados anteriormente. Definitivamente no es la Opción C. - Matthiaspaul ( charla ) 02:06, 20 de febrero de 2021 (UTC)
  • Opción C . Una pérdida de tiempo y energía tan absurda y una enorme fuente de spam en las listas de seguimiento, todo para lograr algo que dificultará la edición . Toohool ( charla ) 02:26, ​​22 de febrero de 2021 (UTC)
  • La opción A como estandarización es mejor a largo plazo. Deje que el bot continúe su trabajo. Si las personas tienen un problema con el spam en su lista de seguimiento, tienen la opción de filtrar las ediciones de los bots. AVS malnad 77 talk 05:59, 23 de febrero de 2021 (UTC)
  • Opción C si no B Si bien me encanta la coherencia, estoy luchando por ver cuál es el problema real aquí. Supongo que el bot puede cambiarlos gradualmente junto con otros cambios más útiles, pero esto es solo cosmético para el código y el desorden de los historiales de edición. Reywas92 Talk 06:21, 24 de febrero de 2021 (UTC)
  • Opción C . Los beneficios para los creadores de bots o plantillas no superan los inconvenientes para otros editores. Fram ( charla ) 08:13, 24 de febrero de 2021 (UTC)
  • C . No veo el argumento para exigir guiones. Simplemente deje que la gente use ambos, la coherencia en esto no importa. Vallas y ventanas 17:00, 24 de febrero de 2021 (UTC)
  • Comentario : mi opción predeterminada es D ... Me niego a usar plantillas de citas y formateo mis citas a mano. Significa que puedo ignorar todos los debates tontos sobre parámetros y qué no. Blueboar ( charla ) 17:49, 24 de febrero de 2021 (UTC)
    Sí, y podemos eliminar instantáneamente la acumulación de WP: PHAB escribiendo artículos con papel y bolígrafo. Podemos resolver muchos problemas tecnológicos abandonando la tecnología. Levivich  acoso / sabueso 00:52, 25 de febrero de 2021 (UTC)
  • Opción C . Los bots hacen un trabajo útil, pero su código se puede cambiar según sea necesario. Aquí estoy mucho más preocupado por los editores habituales que utilizan plantillas de citas cuando realizan ediciones manuales. Estos son seres humanos vivos y hay muchos más que bots. Hacer que la sintaxis de la plantilla sea demasiado rígida hará que su vida sea mucho más desagradable. La flexibilidad adicional es útil y útil para los editores habituales. Nsk92 ( conversación ) 02:26, ​​25 de febrero de 2021 (UTC)
  • Opción C . He estado escribiendo fecha de acceso durante los últimos 15 años aproximadamente, a veces mientras alcanzo mi bebida con la otra mano (teclado Qwerty). ¿Por qué arruinar mi memoria muscular y privarme de un sorbo de té? - gadfium 04:04, 25 de febrero de 2021 (UTC)
  • Opción C según Phil Bridger Sea Ane ( charla ) 21:53, 26 de febrero de 2021 (UTC)
  • Opción C , detén la locura de golpear las listas de seguimiento (aunque la mayor parte de ese daño ya está hecho). Sandy Georgia ( Discusión ) 00:58, 2 de marzo de 2021 (UTC)
  • C suena mejor, seguido de B. La eliminación de parámetros que fueron ampliamente utilizados en el pasado romperá las revisiones antiguas de artículos por muy pocas ventajas prácticas. - Kusma ( t · c ) 11:44, 2 de marzo de 2021 (UTC)
  • Opción C . Otros ya se han dado cuenta de por qué: spam en las listas de seguimiento, pérdida de tiempo y energía sin un beneficio genuino, imposición innecesaria a los editores, etc. Cada vez me entusiasma más la idea de escribir citas manualmente (como alguien más mencionó aquí), solo para evite los retoques constantes que parecen tener lugar con estas plantillas. JG66 ( conversación ) 11:51, 2 de marzo de 2021 (UTC)
  • Opción C por Aquillion. Monkbot nunca debería haber sido aprobado - In actu (Guerillero) Parlez Moi 20:22, 2 de marzo de 2021 (UTC)
  • A o B Esto parece una elección entre tener innecesariamente varias formas diferentes de escribir un parámetro dado y entre estandarizar después del hecho con muchas ediciones menores. Muchos de los argumentos a favor de C parecen presuponer que los editores se meterán en problemas por escribir los parámetros sin guiones, pero no veo evidencia de eso. Jo-Jo Eumerus ( charla ) 10:30, 4 de marzo de 2021 (UTC)
  • Opción A . Por la experiencia del mundo real, entiendo lo difícil que es mantener el código sin una depreciación ocasional. Los temores de los oponentes a una interrupción e inconveniencia inaceptables no coinciden con lo que encontré cuando el bot se estaba ejecutando, y escribir el guión rápidamente se convirtió en una segunda naturaleza. - Worldbruce ( charla ) 05:07, 7 de marzo de 2021 (UTC)
    Es posible que personalmente no haya encontrado interrupciones e inconvenientes, pero yo sí, y hay muchos otros editores en esta y otras discusiones que han informado de interrupciones inaceptables y explicaron exactamente por qué las molestias no están justificadas. Thryduulf ( conversación ) 20:29, 7 de marzo de 2021 (UTC)
  • Opción A . El beneficio a largo plazo hace que valga la pena la interrupción a corto plazo. Hay demasiada inconsistencia en las plantillas que me hace perder mucho más tiempo (por ejemplo, ¿es "image =" o "Image =" o "photo =" en esta plantilla en particular); deberíamos avanzar hacia una mayor coherencia. Apoyaría mantener los parámetros en funcionamiento durante algunos años (pero indocumentados y con una advertencia) para aquellos que realmente están preocupados al escribir el guión, sabiendo que el bot vendrá y los cambiará. MB 15:23, 7 de marzo de 2021 (UTC)
    La mejor solución para "is it" image = "o" Image = "o" photo = "" es simplemente admitirlos todos. De esa manera, no hay necesidad de interrupciones, a corto plazo o de otro tipo. Thryduulf ( conversación ) 20:31, 7 de marzo de 2021 (UTC)
  • Opción A: la estandarización ayuda a simplificar el mantenimiento del código y eso significa que se puede dedicar más tiempo a futuras mejoras. Imzadi 1979  → 17:34, 7 de marzo de 2021 (UTC)
  • La pregunta que tenemos ante nosotros es: ¿Deberían eliminarse por completo los parámetros sin guiones de la familia de plantillas CS1 / 2? Sí, absolutamente, para la mayoría, si no todas, de las razones enumeradas anteriormente. Se debería haber implementado una denominación de parámetros coherente c. 2007, cuando las diversas plantillas cs1 | 2 desarrolladas de forma independiente se convirtieron para utilizarlas como motor de representación de citas común. A principios de 2013, en.wiki migró al Módulo: Cita / CS1{{citation/core}}suite. Desde entonces, aproximadamente 180 wikis de MediaWiki en otros idiomas más algunos wikis que no son de MediaWiki también han migrado a la suite de módulos. Desde que en.wiki cambió al conjunto de módulos, hemos agregado nuevos nombres de parámetros para admitir nuevas funciones y, al mismo tiempo, hemos eliminado bastantes nombres de parámetros debido a la redundancia, el estilo de nombre peculiar, la falta de uso y otras razones. Esta reducción incluye la mayoría de los nombres de los parámetros de varias palabras nonhyphenated de manera que hoy, la única restantes nombres de los parámetros nonhyphenated son |accessdate=, |archivedate=, |archiveurl=, |authorlink=(y sus dos formas enumeradas), y|origyear=(hay 263 nombres de parámetros básicos y 77 nombres de parámetros enumerados). La adopción mundial del conjunto de módulos cs1 | 2 nos ha llevado a agregar soporte para la internacionalización. Los wikis que no están en inglés y que emplean el conjunto de módulos cs1 | 2 deben conservar todos los nombres de los parámetros en inglés porque, muy a menudo, los artículos desarrollados en en.wiki se exportan y traducen a esos otros idiomas. Eso significa que un conjunto de módulos completamente implementado en una wiki que no esté en inglés debe admitir los 340 nombres de parámetros en inglés más 340 nombres de parámetros locales. Creo que es mejor tener un solo estilo coherente para los nombres de parámetros de varias palabras para que los editores de traducción no tengan que aprender o tratar con nombres de parámetros redundantes (esto mismo se aplica a los editores principiantes en en.wiki). Las plantillas cs1 | 2 son lo suficientemente complejas, noNo es necesario aumentar esa complejidad manteniendo listas de nombres de parámetros sinónimos que no tienen significado semántico (por ejemplo,|chapter=, |article=, |entry=, |section=, Etc, son tratados por CS1 | 2 como sinónimos, pero, a editores, transmitir diferentes significados - la inclusión u omisión de un guión transmite ninguna distinción significativa). Así que sí, los parámetros sin guiones [deberían] eliminarse por completo de la familia de plantillas CS1 / 2 y, dado que no podemos volver a 2007 para hacer lo que deberíamos haber hecho entonces, deberíamos hacerlo ahora, deberíamos hacerlo rápidamente, y deberíamos hacerlo. A es mi opción preferida pero, si es necesario, entonces (suspiro) B ; nunca esa otra opción. - Trapense el monje ( charla ) 00:50, 8 de marzo de 2021 (UTC)
    Gracias por opinar, trapense; Ojalá lo hubieras hecho hace un mes. Su explicación es persuasiva, pero sigo pensando que la Opción A es una tontería si no cambiamos al menos simultáneamente la documentación para decirle a los usuarios, "no use más ese parámetro". Hacer que los bots luchen contra los editores humanos es tonto e ineficiente y posiblemente incluso peligroso . -  JohnFromPinckney ( charla ) 02:03, 8 de marzo de 2021 (UTC)
    Entonces, para resumir los argumentos de Trappist: es mucho más fácil para los desarrolladores tener solo unos pocos nombres, por lo que deberíamos interrumpir a los editores y, por lo tanto, a la wiki para hacerles la vida más fácil, independientemente de los costos (se explicó en detalle anteriormente cómo tener dos nombres hace lo mismo no es en absoluto un problema para los editores). Lo siento, pero eso no es convincente en lo más mínimo: las plantillas existen para ayudar a los editores y no al revés. Thryduulf ( charla ) 03:06, 8 de marzo de 2021 (UTC)
    No. El trapense no dijo tal cosa. Explicó amablemente por qué es necesario este cambio. Con la posible excepción de las listas de seguimiento, este cambio no "perturba seriamente a los editores" (no hay forma de que tener que escribir un carácter adicional sea un problema de esa magnitud); por el contrario, a la larga, que hace la vida más fácil para los editores, ya que sólo hay un simple, fácil de recordar regla: todos los parámetros de palabras muti-utilizan un guión para separar las palabras. En las listas de seguimiento, consulte la nota #Vale la pena a continuación, que parece ser una solución prometedora. Y si lo peor llega a lo peor y esa solución no funciona para usted, entonces simpatizo, pero al menos la "interrupción" es solo temporal hasta que el bot esté terminado. - NSH001 ( hablar) 10:05, 8 de marzo de 2021 (UTC)
    No, la interrupción no es temporal. No solo es probable que la gente continúe usando los parámetros "antiguos", sino que eliminar el soporte para estos parámetros de las plantillas significa que millones de revisiones antiguas tendrán errores en ellos en lugar de simplemente mostrar las referencias como solían hacerlo. ¿Creando errores en las referencias de versiones antiguas de infinidad de páginas, de modo que solo tengas que mantener 340 en lugar de 349 parámetros (bueno, ni siquiera eso, 340 parámetros + 9 sinónimos)? Eso parece una gran interrupción por poco beneficio. Fram ( charla ) 11:13, 8 de marzo de 2021 (UTC)
    Realmente no importa, es relativamente poco común citar versiones antiguas de páginas, y los mensajes de error se pueden ignorar con seguridad; solo importa la última página. También sufren de plantillas eliminadas (que pueden ser mucho más graves para la página tal como se muestra realmente al usuario) y wikilinks que se han vuelto rojos porque la página de destino ha sido eliminada. Sin duda otras cosas en las que no he pensado todavía. Uno simplemente acepta estas imperfecciones. No "interrumpe" nada seriamente. - NSH001 ( conversación ) 14:05, 8 de marzo de 2021 (UTC)
    Un enlace rojo porque el objetivo no existe no es un problema (incluso es una mejora). Los otros son problemas, y agregar a sabiendas mucho, mucho más de lo mismo es un problema serio. Una versión de Salvador Dalí de hace 5 años ya tiene unos 10 errores: los de lang text son los más molestos. Pero la eliminación planificada de, por ejemplo, fecha de acceso, de repente agregará aquí 24 errores adicionales. Básicamente, cada edición que MonkBot haga para estos significará uno o más errores en cada revisión del historial, o millones y millones de versiones antiguas que empeorarán, y ninguna versión actual de versiones futuras que mejorarán. Fram ( charla ) 14:33, 8 de marzo de 2021 (UTC)
  • Opción C Y esta cuestión es en gran parte la razón por la que estoy en la posición actual. BAG no es adecuada para este propósito y necesita ser destruida desde la órbita. Solo en la muerte termina el deber ( conversación ) 15:31, 8 de marzo de 2021 (UTC)
    La BOLSA tiene algunas funciones. Hace un buen trabajo con algunos de ellos, en particular, es bastante bueno para garantizar que los bots hagan solo lo que sus autores pretenden que hagan antes de que se desaten. El problema principal es garantizar que solo se aprueben las tareas con consenso por hacer y el consenso para que un bot haga el trabajo; no recuerdo una instancia en la que no aprobó algo que debería aprobarse, y realmente detiene el Las ideas terriblemente malas de proceder, pero hay varios casos (incluido este) en los que el listón para el consenso se ha establecido demasiado bajo y un pequeño consenso local ha permitido que un bot sin la aprobación de la amplia comunidad opere. Si tenemos bots, entonces necesitamos algún tipo de proceso de aprobación, así que no destruyas el que tenemos sin pensar primero en algo mejor.Thryduulf ( hablar) 16:54, 8 de marzo de 2021 (UTC)

Discusión (CS1) [ editar ]

Algunas sugerencias sobre las opciones:

  • Pedantería: "Parámetros sin guiones" debe leer "Parámetros de varias palabras sin guiones" en las tres opciones. Los parámetros que contienen solo una palabra o un acrónimo no necesitan un guión.
  • En la Opción C, no tiene sentido sugerir que "la lista de parámetros obsoletos deberá actualizarse para eliminar los parámetros sin guiones"; no quedan instancias de esos parámetros obsoletos en los espacios de nombres afectados, por lo que la compatibilidad con ellos se eliminará en breve, al igual que ya se eliminó la compatibilidad con docenas de parámetros de varias palabras sin guiones.

Un poco de historial y una actualización de estado, para aquellos aquí en VPP que no están familiarizados con el largo historial de actualizaciones y cambios en las plantillas de Citation Style 1 ({{ cite web }} y sus hermanos): por lo que puedo decir, solo hay seis sin guiones parámetros de varias palabras a la izquierda - |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, y|origyear=- de una población original de muchas docenas. Hasta ahora, a través del trabajo de decenas de editores y bots durante los siete años desde que estandarizamos la separación por sílabas de los parámetros de varias palabras, hemos desaprobado, eliminado de las páginas en los espacios de nombres afectados y luego eliminado de las propias plantillas de CS1 (como sugiere WhatamIdoing arriba), muchas docenas de diferentes parámetros de varias palabras sin guiones en las plantillas CS1 / CS2. Todos los nuevos parámetros de varias palabras durante ese tiempo se han introducido utilizando solo una forma con guiones. Básicamente, este RFC se pregunta: ¿deberíamos terminar el trabajo o dejarlo en más del 90%, en una especie de estado de limbo, con seis parámetros como excepciones al patrón general, solo porque esos parámetros se utilizan en muchos artículos? - Jonesey95 ( hablar) 04:38, 11 de febrero de 2021 (UTC)

  • Problema con la "opción B": la opción B no es el statu quo. Si lo fuera, sería mucho más feliz. Como no lo es, no sé si votar por A o B. La documentación en Cite web , por ejemplo, no menciona que accessdateesté obsoleta. Esto significa que los usuarios estarán bastante justificados para agregar y leer felizmente plantillas con accessdate, incluso después de que el bot ya haya llegado y haya cambiado accessdatea access-date20 lugares. Cada iteración tiende a abordar menos instancias, pero cada ejecución es una entrada separada en mi lista de seguimiento. Las entradas de la lista de vigilancia parecen ser parte de la queja contra este tipo de trabajo, por lo que el primer paso debería ser cerrar el grifo en la fuente, antes de gastar energía para, um, rescatar el barco.-  JohnFromPinckney ( charla ) 06:37, 11 de febrero de 2021 (UTC)
    • La primera oración es verdadera; todos menos seis de los parámetros de varias palabras sin guiones han sido formalmente obsoletos y eliminados. En cuanto a "cerrar el grifo en la fuente", esa sería la Opción A, pero en el pasado, cuando hacíamos que aparecieran mensajes de error rojos en una gran cantidad de artículos como primer paso para estandarizar las plantillas de citas y anotar errores en ellas , ha habido un retroceso significativo. Para evitar ese retroceso, el bot estaba actuando para corregir el 90 +% de los parámetros no estándar antes de activar los mensajes de error, pero ese trabajo también se detuvo. La opción A permitirá que se complete ese trabajo. - Jonesey95 ( charla ) 15:09, 11 de febrero de 2021 (UTC)
      • Siento que no nos entendemos. La "desaprobación" implica la comunicación como primer paso; la eliminación es un segundo paso posterior. Si vamos a tener un bot que cambia de página ( por ejemplo , accessdatea access-date), causando algo de angustia a la población (y este es el status quo), entonces al menos deberíamos cambiar la documentación para decir que accessdateestá obsoleta y que no es utilizable. alias. Estoy firmemente en contra de que un bot cambie los parámetros a los nombres "buenos" cuando nunca les decimos a los humanos que no deben usar los "malos". Eso es solo un ciclo interminable de ediciones que abarrotan las listas de observación y causan una gran irritación. Si desea evitar el rechazo, dígale a la gente que no use las versiones sin guión,entoncesejecute el bot, luego elimine el soporte algún tiempo después. -  JohnFromPinckney ( charla ) 15:41, 11 de febrero de 2021 (UTC)
        • Desaprobar en términos de las plantillas de CS1 significa emitir un mensaje de error rojo que indica desaprobación. Cuando emitimos mensajes de error rojos para los parámetros en CS1 que se usan con frecuencia (o la falta de los mismos para los parámetros que deberían usarse con más frecuencia), mucha gente se enoja mucho. No cambiamos la documentación para indicar la desaprobación hasta después de que el módulo comience a informar a las personas en línea sobre la desaprobación. Entonces sí, no se están entendiendo, pero es una cuestión de términos artísticos. - Izno ( conversación ) 16:44, 11 de febrero de 2021 (UTC)
          • ¿Por qué la gente se enoja? Porque, de repente, millones de lectores pasan de que nada va mal a ver una gran cantidad de mensajes de error rojos en cientos de miles de artículos (y no se puede esperar seriamente que alguien depure un error de CS1 como su primera contribución). Estas plantillas de citas no son para nosotros. Son para el lector y deben ser funcionales con una baja tasa de mensajes de error las 24 horas del día, los 7 días de la semana, sin excepción, porque incluso pequeñas cantidades de tiempo de inactividad tienen un daño significativo a la reputación. - Bilorv ( conversación ) 02:54, 15 de febrero de 2021 (UTC)
            • Sería más comprensivo con ese argumento de "daño significativo a la reputación" si no hubiera más de 100,000 páginas con errores activos en ellas (y eso es ignorar la Categoría oculta : errores CS1: publicación perdida ) y otras 250k en su hermana (también oculto). - Izno ( charla ) 20:22, 15 de febrero de 2021 (UTC)
      • Que "nosotros" (¿quién es ese, una clase de supertecnologías cuyas opiniones cuentan mucho más que aquellos de nosotros los editores "normales"?) Tengamos un rechazo significativo al crear mensajes de error es simplemente una demostración de que la comunidad en general no está de acuerdo lo que "nosotros" hemos decidido. La respuesta es dejar de hacer lo que está haciendo, no hacerlo más sigilosamente. Phil Bridger ( charla ) 18:37, 11 de febrero de 2021 (UTC)
        • Le invitamos a participar en Help talk: CS1 , al igual que cualquier otro editor. Las decisiones se toman por consenso allí, en línea con la forma en que se practica el consenso en cualquier otro lugar de la wiki. ¿No le gusta una decisión que "nosotros" tomamos? Involucrarse. - Izno ( charla ) 18:42, 11 de febrero de 2021 (UTC)
          • No vi absolutamente ninguna discusión sobre la eliminación del campo de editores de texto libre en la página de discusión. ¿Dónde sucedió eso? No creo que sea una coincidencia que todos los editores cuyos nombres conozco bien por la creación / edición de contenido estén votando B / C y todos los editores que votan A sean aquellos que no reconozco en absoluto. Espresso Addict ( charla ) 20:08, 11 de febrero de 2021 (UTC)
            • La diferencia está entre las personas que piensan que esto es una enciclopedia y las que piensan que es un patio de recreo para los técnicos. Phil Bridger ( charla ) 20:43, 11 de febrero de 2021 (UTC)
              • Su ad hominem no es bienvenido aquí. Siga adelante si eso es lo mejor que puede ofrecer a la discusión. - Izno ( conversación ) 20:47, 11 de febrero de 2021 (UTC)
                • Ese es el tipo de respuesta que las personas que están aquí para crear una enciclopedia tienden a recibir de los técnicos. No hay respuesta a preocupaciones genuinas, sino simplemente una orden de "seguir adelante". No deseo monitorear las páginas que se usan para ignorar a los usuarios finales, pero tengo derecho a esperar que las decisiones que se tomen respeten los intereses de todos, no solo una camarilla autoproclamada de personas que "saben" lo que es correcto. Phil Bridger ( charla ) 19:53, 15 de febrero de 2021 (UTC)
                  • Es el tipo de respuesta a las personas que crean innecesariamente la categoría A y la categoría B y luego se alinean en una u otra categoría. Si usted (específico / personal) no desea monitorear las páginas, esa es su prerrogativa. Sepa que es su elección y usted es responsable de esa elección, y las elecciones tienen consecuencias. Los cambios siempre se anuncian con anticipación y se busca consenso para cambios no obvios (e incluso cambios obvios con implementaciones no obvias), por lo que no tiene excusa para no sintonizar al menos una vez cada dos meses cuando el habitual "Shit is Changing "se realiza la publicación. En segundo lugar, las citas de miedo no están indicadas por esta discusión, ni ninguna discusión previa que pueda ver, en absoluto. No he visto tal 'camarilla' ni a ninguno de los usuarios que posiblemente estarían en tal 'camarilla 'afirman que "saben" lo que es correcto. Como dije, si no tienes nada que aportar más que difamaciones, ataques y divisiones, sigue adelante. -Izno ( charla ) 20:22, 15 de febrero de 2021 (UTC)
            • En orden cronológico inverso: las notas del parche que indican la eliminación , la discusión sobre la eliminación , las notas del parche que indican la desaprobación , la discusión sobre la desaprobación . 4 veces mencionado durante un período de medio año en esa página de discusión, una categoría de mantenimiento preexistente que indica una depreciación leve y mi eliminación de más de 4k instancias del parámetro durante el año y medio anterior a la discusión de la depreciación. Básicamente a mano ( mi mano, da la casualidad). - Izno ( charla ) 20:45, 11 de febrero de 2021 (UTC)
            • En cuanto a , no creo que sea una coincidencia que todos los editores cuyos nombres conozco bien por la creación / edición de contenido estén votando B / C y todos los editores que votan A sean aquellos que no reconozco en absoluto. , Te invito igual que invité a Phil Bridger. Puede ver y editar Help talk: CS1 en cualquier momento, al igual que yo. "No reconozco a esta gente" es una asociación basura y es el mismo tipo de ad hominem que le he pedido a Phil tan amablemente que deje de emplear. Ciertamente, no es motivo suficiente para decir "No me gusta este cambio". - Izno ( charla ) 20:49, 11 de febrero de 2021 (UTC)
              • Creo que hay un problema genuino aquí: hay una desconexión entre los editores que mantienen las plantillas de citas y los editores que las emplean para escribir y mantener los artículos. No tomé la decisión de abandonar años de uso de plantillas de citas (CS2 en realidad, pero los mismos cambios de parámetros están sucediendo allí también, incluso menos anunciados) a la ligera. Espresso Addict ( charla ) 21:35, 11 de febrero de 2021 (UTC)
                La desconexión es real y significativa. Alguien cuyas habilidades e interés radica en escribir o mantener el contenido del artículo no debería tener que preocuparse por lo que sucede en páginas como Help talk: CS1 (¿y cómo diablos se supone que un nuevo editor debe saber que esa página existe?), Y mucho menos tener para prestar atención a las discusiones allí. Aquellos que se preocupan por la mecánica de las plantillas siempre deben actuar de manera que pongan activamente a los lectores en primer lugar, a los editores en segundo lugar y a los programadores en tercer lugar. La única vez que debería haber cambios importantes o una necesidad de ediciones cosméticas es cuando, después de un examen detallado, literalmente no hay alternativas disponibles. Terminamos aquí porque eso no ha estado sucediendo y un consenso local ha ignorado las necesidades de los usuarios finales. Thryduulf ( hablar) 01:38, 12 de febrero de 2021 (UTC)
                Casi comento anoche, y luego puse esa versión en un archivo de texto y me fui a la cama. Ahora, un comentario anterior me ha estimulado a responder aquí. Los editores que utilizan estas plantillas para escribir y mantener artículos son los mismos que los editores que mantienen las plantillas de citas. Métete eso en la cabeza. Si priorizamos diferentes cualidades frente a este otro supuesto grupo separado, es porque tenemos la experiencia para hacerlo. Si no lo hace, permítame reiterarlo, involúcrese. Venga y diga "No me gusta esto" o "esta es una interacción dolorosa" o X, Y y Z, y proporcione una solución sugerida. Así es como comienza a formarse el consenso, como cualquier otra página o proceso en este sitio web. Otros dirán "No quiero que esto funcione como la solución sugerida porque A, B y C".Luego, discute las compensaciones y toma una decisión. Si no está dispuesto a dar un paso al frente y discutir los recortes de papel, entonces terminamos teniendo RFC masivas o un drama de AN o lo que sea sobre lo que de otra manera serían problemas pequeños o problemas que podrían haberse discutido informalmente con la gente común ". hacia fuera "visión de consenso del mundo. Eso también es una desconexión, y culpar a los editores interesados ​​en una página frente a aquellos aparentemente desinteresados ​​no es la forma correcta de avanzar. ¿Quieres algo mejor? Pedir. Proponer. Engatusar. Haga el esfuerzo de presentar la menor de las interacciones sociales necesarias para iniciar una discusión en el único lugar donde se discute todo sobre ese tema. Todos somos voluntarios y nuestro corazón está en un lugar adecuado como el suyo, pero si tuviéramos desacuerdos,luego hablamos entre nosotros y averiguamos cómo solucionar el problema o acordamos estar en desacuerdo sobre los puntos de interés. No tener quejas constantes de "no me escucharon".El consenso no es unanimidad .
                La única vez que debería haber cambios importantes o una necesidad de ediciones cosméticas es cuando, después de un examen detallado, literalmente no hay alternativas disponibles. Francamente, esta es una opinión que carece de consenso comunitario alguno. Recientemente aprobamos un RFC que permite ediciones cosméticas de forma regular y por lo que pude ver en esa discusión (y murmullos en otros lugares), las ediciones cosméticas podrían estar más cerca de tener consenso que no, es solo la inercia lo que nos deja sin realizarlas con regularidad. . Además, cientos de plantillas, y ciertamente todas las que pasan por WP: TFD, tienen un proceso aplicado que causa cambios importantes o que da como resultado ediciones más o menos cosméticas. ¿Está afirmando que TFD no tiene consenso como proceso? ¿Las plantillas que se están limpiando debido a una discusión en la página de discusión en la página de discusión de esa plantilla deberían detenerse? Quieres tu pastel (que no le importe cómo funcionan las cosas) y comértelo también (haz que se escuchen todas tus opiniones y afirmaciones, cuando ni siquiera están articuladas en primer lugar). Ser realistas. - Izno ( charla ) 20:22, 15 de febrero de 2021 (UTC)
                Me temo que esto solo demuestra la verdad de lo que escribe Thryduulf . "Los editores que usan estas plantillas para escribir y mantener artículos son los mismos que los editores que mantienen las plantillas de citas. Consíguelo en tu cabeza". es evidentemente falso, además de descortés. Hablando solo por mí mismo, lo que realmente quiero es poder seguir escribiendo y mejorando artículos, en lugar de tener largas discusiones paralelas sobre asuntos que no son directamente relevantes. Espresso Addict ( charla ) 00:10, 16 de febrero de 2021 (UTC)
                continúe escribiendo y mejorando artículos. Entonces hágalo. Nadie te está impidiendo que no te importe. Solo lo llamo hipócrita por armar un escándalo cuando no lo hace y luego ocurren cambios en otros lugares que lo afectan. ¿No te gusta? Cambia tu comportamiento. (No te responderé de nuevo) - Izno ( charla ) 00:34, 16 de febrero de 2021 (UTC)
                Los editores que utilizan estas plantillas para escribir y mantener artículos son los mismos que los editores que mantienen las plantillas de citas. Métete eso en la cabeza.Ambos descorteses y ni siquiera cerca de lo correcto. Si bien es posible que algunos, quizás incluso muchos, de los editores que mantienen plantillas también escriben y mantienen artículos, hay literalmente cientos de editores que escriben y mantienen artículos que nunca han estado cerca de una discusión sobre el código de la plantilla, y mucho menos escrito ningún código. Escribir prosa enciclopédica y escribir código de computadora son habilidades muy diferentes; nadie está obligado a hacer ambas cosas. Sin embargo, dado que el propósito de este proyecto es escribir una enciclopedia, todo lo que no sea escribir una enciclopedia debe hacerse en beneficio de (ante todo) los lectores de la enciclopedia y (en segundo lugar) de quienes escriben y mantienen la enciclopedia. La conveniencia de quienes manejan herramientas es lo menos importante. Thryduulf ( hablar) 00:23, 16 de febrero de 2021 (UTC)
                Escribir prosa enciclopédica y escribir código de computadora es una dicotomía falsa y una tergiversación flagrante de los dos párrafos que tenía que decir. No te pedí que hicieras ambas cosas. Tampoco le sirvo (en general) en su supuesto papel de redactor de artículos. No hay jerarquías (formales) en esta enciclopedia, e incluso considerarte a ti mismo como supuestamente por encima de mí o de mis esfuerzos es la verdadera declaración descortés. Por último, me coloco de lleno en ambos supuestos grupos dados los miles de artículos en los que he mejorado sus citas. (Y como le dije a Espresso, no volveré a responder en esta sección.) - Izno ( charla ) 00:34, 16 de febrero de 2021 (UTC)
                Mi papel aquí no es el de redactor de artículos (hago muy poco de eso), paso la mayor parte de mi tiempo en el proyecto tratando de asegurarme de que los lectores puedan encontrar el contenido que buscan y los que escriben y mejoran artículos sin tener que preocuparse por tonterías como esta que innecesariamente harán su trabajo más difícil. Puede que no haya una jerarquía formal, pero debería ser: (1) Los lectores están muy por encima de los demás. (2) Aquellos que escriben y mantienen la enciclopedia están muy por encima (3) Aquellos que apoyan a aquellos que escriben y mantienen la enciclopedia están muy por encima (4) Aquellos que obstaculizan cualquiera de los anteriores. Me coloco en la tercera categoría junto a muchos de los que mantienen plantillas. Thryduulf ( conversación ) 21:02, 16 de febrero de 2021 (UTC)
  • Comentar . ¿Cuál es el mérito de las plantillas de citas? ¿Y mucho menos el aumento de la fluencia para hacerlos cada vez más rígidos y más difíciles de usar? La única razón que veo es para facilitar la exportación y la venta de datos. Nadie parece pensar en aquellos que escriben citas manualmente; es mucho más difícil escribir "fecha de acceso" (que requiere dos manos y un movimiento de la mano) que "fecha de acceso" (una mano, sin movimiento). No entiendo en absoluto cuál es el beneficio de este cambio. De hecho, ampliando esta discusión, no entiendo por qué el campo de los editores de texto libre se retiró repentinamente este enero. Personalmente, he decidido afrontar este último cambio volviendo a escribir las referencias a mano, que es más fácil, más flexible y parece no tener inconvenientes.Adicto al espresso ( hablar) 07:04, 11 de febrero de 2021 (UTC)
    • Las plantillas de citas facilitan la estandarización del estilo de las citas y su apariencia. Pueden, por ejemplo, estandarizar automáticamente la visualización de la fecha. La legibilidad por máquina también es algo bueno, en mi opinión. Supongo que la fecha de acceso es un poco más difícil de escribir, pero a los editores que editan wikitext manualmente probablemente no les importe. De lo contrario, existen herramientas para insertar estas citas. Elliot321 ( discusión | contribuciones ) 17:12, 11 de febrero de 2021 (UTC)
      • No es un poco más difícil de escribir, es mucho más difícil de escribir para un mecanógrafo táctil. Y aquí hay un editor que edita el wikitexto manualmente a quién le importa, lo suficiente como para molestarse en responder aquí. No conozco ninguna herramienta que cree código de plantilla de citas en la forma que prefiero para facilitar la edición posterior del wikitexto; todos hacen una sopa de código que lleva más tiempo arreglar que volver a escribir. Espresso Addict ( charla ) 20:08, 11 de febrero de 2021 (UTC)
        Un poco más lento, sí, pero personalmente no lo encuentro mucho más difícil; los mecanógrafos táctiles generalmente lo han practicado mucho mientras aprenden. No obstante, no creo que la facilidad para escribir según alguna métrica sea el problema principal. isaacl ( charla ) 20:40, 11 de febrero de 2021 (UTC)
        Hablando como uno de esos mecanógrafos táctiles, y como una persona que aprendió a escribir en una máquina de escribir real, no encuentro la versión con guiones más difícil de escribir, y recuerdo a mi profesor de mecanografía diciendo que era más rápido y más fácil de escribir. escriba palabras que se dividieron uniformemente entre las manos, en lugar de todas en una mano. WhatamIdoing ( charla ) 22:49, 11 de febrero de 2021 (UTC)
        Sí, personalmente me imagino que tiene un efecto mayor para un mecanógrafo de caza y picotazo. Cuando dije un poco más lento, estaba pensando en comparación con una palabra de igual longitud que solo constaba de letras. Por supuesto, en este caso, el nombre con guión tiene un carácter más que comprendería la mayor parte de la diferencia para mí. isaacl ( charla ) 23:02, 11 de febrero de 2021 (UTC)
        Para mí, no es un problema en un teclado normal, sino un poco molesto en una tableta. Por otra parte, tanto es un poco doloroso en una tableta ... · · · Peter Southwood (charla) : 05:39, 2 de marzo de 2021 (UTC)
      • Yo mismo utilizo plantillas de citas, pero respeto los deseos de quienes prefieren no usarlas. Es precisamente el hecho de que los utilice lo que me lleva a la opinión de que los sinónimos obvios de parámetros no deberían eliminarse, como se propone aquí. ¿Cuál es el problema de la Tierra con permitir formas con guiones o sin guiones? Todo lo que significa son unos pocos bytes adicionales de almacenamiento y ningún código adicional si se hace correctamente. Y el trabajo ya está hecho, pero esta propuesta es para deshacerlo. ¿Seguimos viviendo en los días en que comencé en TI trabajando para una de las compañías de información empresarial líderes en el mundo cuyas operaciones en el Reino Unido se ejecutaban desde una computadora con 1 MB de memoria y donde todos los programas en línea estaban limitados a 12 KB? Pensé que habíamos avanzado desde allí. Phil Bridger ( hablar) 20:34, 11 de febrero de 2021 (UTC)
        Recuerdo la historia de una señora que (hace décadas) compró una gran cantidad de material de oficina personalizado y luego descubrió que la oficina de correos estaba cambiando el nombre de su calle. Convenció al administrador de correos local para que le permitiera seguir usando la dirección anterior hasta que se agotara su papelería. Esto le ahorró algo de dinero y esfuerzo, pero tuvo costos externos. Durante muchos años, cada cartero tuvo que aprender que "123 Main Street" no estaba en Main Street y no era el número 123, sino que tenía que ser entregado al otro lado de la ciudad.
        Los alias suelen ser de bajo costo en términos de almacenamiento y computacionales, pero en realidad no son gratuitos. "No es gratis" puede sumar un costo bastante significativo cuando se repite un millón de veces. WhatamIdoing ( charla ) 22:56, 11 de febrero de 2021 (UTC)
  • Aunque simpatizo con el deseo de que todas las plantillas se alineen con un estándar (desde la perspectiva de un usuario, personalmente lo encontraría más fácil), simplemente no creo que sea factible en este momento. En cuyo caso, simpatizo con aquellos que piensan que las computadoras deberían hacernos la vida más fácil y simplemente aceptan ambos formatos. En tercer lugar, desde la perspectiva de un implementador, aprecio que agrega mucho ruido a la sintaxis de la plantilla, si no se implementa con un módulo Lua. Dado que las plantillas basadas en CS1 se implementan con Lua, la sobrecarga se puede minimizar, por lo que creo que ambos formatos deberían seguir siendo compatibles. No creo que haya muchas ventajas en convertir en masa, por ningún mecanismo. isaacl ( charla ) 20:40, 11 de febrero de 2021 (UTC)
  • Haciendo ping a algunos participantes anteriores en conversaciones relacionadas que pueden no estar al tanto de esta discusión: @ SandyGeorgia , Jason Quinn , Oknazevad , Tom.Reding , Brainulator , DavidBrooks , SMcCandlish , David Eppstein , Matthiaspaul , Headbomb , Gracefool , Ss112 , JG66 , Mikeblas , Gonzo fan2007 , Sariel Xilo , genio modesto , y SlimVirgin : . Nikkimaria( charla ) 01:17, 12 de febrero de 2021 (UTC)
    Gracias por el ping, de hecho no estaba al tanto de esta discusión. Modest Genius talk 12:16, 12 de febrero de 2021 (UTC)
  • ¿Alguien tiene alguna evidencia de que tener un alias para los parámetros dificulta las cosas para los usuarios finales? En mi experiencia como capacitador y usuario desde hace mucho tiempo, tener múltiples formas de lograr los mismos fines permite a los editores dedicar su tiempo y energía a trabajar en el contenido en lugar de preocuparse por asegurarse de que los parámetros de la plantilla estén nombrados exactamente de la manera correcta. Nunca he conocido a nadie que se sintiera lo suficientemente cómodo como para tratar con plantillas en primer lugar que no se sintiera completamente cómodo con la idea de que "puedes escribirlo como fecha de acceso o fecha de acceso, no hace ninguna diferencia". (o similar). Hablando personalmente, no quiero tener que saber si es "fecha de acceso", "fecha de acceso", "fecha de acceso" o "fecha de acceso",Solo quiero que todos sean aceptados para que lo que ingrese en la plantilla funcione y pueda preocuparme por cosas más importantes.Thryduulf ( conversación ) 01:29, 12 de febrero de 2021 (UTC)
    La inconsistencia en todas las plantillas dificulta las cosas. Los usuarios deben recordar qué plantillas solo admiten un formulario y cuál, o buscarlas cada vez. Sin embargo, aprecio que hay una complejidad adicional al tratar de admitir muchos alias, particularmente para aquellos que no se implementan con un módulo Lua (o cada uso se volverá más elaborado y detallado, o la plantilla podría delegar la implementación detallada a una plantilla auxiliar, y la de nivel superior solo realiza la normalización de parámetros), por lo que personalmente no querría exigir que todas las plantillas admitan el alias. Por lo tanto, creo que estamos atrapados en la inconsistencia. isaacl ( charla ) 02:12, 12 de febrero de 2021 (UTC)
    Esta inconsistencia debe tolerarse. Algunas plantillas, particularmente de uso intensivo, que tienen alias, son importantes para la gran cantidad de personas que usan estas plantillas. No tienen que recordar si fue |access-date=o |accessdate=. Si no funciona en otra plantilla, está bien. Pero eliminar los alias y simplemente hacer que la computadora diga que no en todas las plantillas hace que las cosas sean mucho más difíciles para la gran mayoría de los usuarios. Ese inconveniente es mucho mayor que el hecho de que algunas plantillas menos utilizadas no admiten alias y es posible que deba echar un vistazo a la documentación a veces. -  Finnusertop ( charla ⋅ contribuciones ) 06:05, 12 de febrero de 2021 (UTC)
    Sí, como dije en otro comentario, creo que ambos formularios deberían seguir siendo compatibles con las plantillas basadas en CS1. Estoy bastante seguro de que la gran mayoría de las plantillas no admiten parámetros con guión y sin guiones; por ejemplo, por lo que puedo decir del código y una prueba rápida, {{ Infobox }} no lo hace. Así es como se trata de hacer que tantos aspectos del marcado de Wikipedia sean accesibles a tantos editores como sea posible: la estandarización no siempre sucederá y, a menudo, más editores preferirán un marcado más simple que un marcado más complejo, incluso si así fuera agregue más funcionalidad para los usuarios. isaacl ( hablar ) 22:22, 12 de febrero de 2021 (UTC)
  • En la Opción C, no tiene sentido sugerir que "la lista de parámetros obsoletos deberá actualizarse para eliminar los parámetros sin guiones"; no quedan instancias de esos parámetros obsoletos en los espacios de nombres afectados, por lo que la compatibilidad con ellos se eliminará en breve, al igual que ya se eliminó la compatibilidad con docenas de parámetros de varias palabras sin guiones. Este argumento va directamente en contra de WP: FAITACCOMPLI . Además, deje de referirse a ellos como "depreciados"; está claro que no hubo consenso suficiente para declararlos depreciados en primer lugar. Puedo entender que es frustrante que algo que pensaba que se había decidido se derrumbara de esta manera, pero es extremadamente importanteque los cambios radicales generan más discusión antes de ser implementados; la única forma en que podemos alentarlo razonablemente es negándonos a permitir cosas como el uso de Monkbot aquí para determinar la política, es decir. es necesario hacer que el trabajo que hizo sea discutible, o la gente tendrá un incentivo constante para tomar la ruta fácil y evitar molestarse en discusiones que consumen mucho tiempo, a menudo frustrantes e impredecibles (pero necesarias) antes de un cambio de esta magnitud. Eso significa, sí, permitir e incluso alentar a las personas a que reanuden el uso de parámetros sin guiones aunque pensaba que finalmente había terminado con ellos; Si desea evitar que eso suceda la próxima vez, busque discusiones a mayor escala primeroantes de hacer cambios a gran escala para evitar un retroceso inesperado si resulta que no tiene el consenso que pensaba que tenía. No importa cuán bien intencionado haya sido esto, no podemos arriesgarnos a recompensar el uso de una herramienta para hacer un cambio generalizado sin un consenso suficiente, lo que significa, sí, por doloroso que sea, llevar deliberadamente la llave a las rótulas de la mejora que se pretendía establecer con este cambio e intencionalmente arruinarla incluso después de que se haya pagado el "costo". No es ideal , pero muestra por qué es tan importante tener discusiones amplias que involucren a muchos usuarios antes de realizar cambios generalizados; tener política establecida efectivamente por bots que realizan ediciones masivas y establecen cosas como hechos consumadossimplemente no es aceptable. Puedo simpatizar con la cantidad de trabajo que se invirtió en esto y que, como resultado, se desperdiciará, pero llegar a un consenso claro e inequívoco que involucre a un gran número de editores debería haber sido el primer paso para algo de esta magnitud, por lo que no lo haría. de repente, te encuentras con un RFC como este y descubres que el consenso no era lo que pensabas. - Aquillion ( charla ) 10:07, 4 de marzo de 2021 (UTC)

Descanso arbitrario 1 [ editar ]

  • Gracias a Nikkimaria por el ping basado en mi participación anterior. Soy terriblemente neutral (o desgarrado) sobre el tema principal, pero antes hice un análisis que me preocupa sobre los impactos en el espacio de la plantilla en particular, si la depreciación continúa por completo. Aquí lo usaré |authorlink=como proxy para los seis, porque personalmente lo escribo con más frecuencia. Hay tres áreas que me preocupan: las plantillas que invocan indirectamente a CS1, las que transcluyen las plantillas que invocan a CS1 y los clones. Me preocupa dónde y cuándo aparecen los mensajes de error rojos, y la documentación, en la que incluyo / doc y TemplateData .
  1. Hay muchas plantillas compatibles con CS1 que invocan una de las plantillas canónicas; {{ Cite la enciclopedia }} se utiliza a menudo, por ejemplo. Algunos utilizan el parámetro de reescritura, la conversión |authorlink=a |author-link=antes de pasarlo.
    1. ¿Tiene siempre precedencia su documentación |author-link=? Creo que los capturamos a todos durante la discusión anterior, pero no puedo garantizar la calidad de la búsqueda.
    2. Debido a que el código CS1 nunca ve el parámetro obsoleto, ¿debería esta plantilla emitir un error rojo durante la sustitución? ¿O tal vez simplemente olvídese del mapeo y haga que CS1 lo haga? ¿Y qué tan difícil es encontrar plantillas con el código de sustitución de parámetros?
    3. Si |authorlink=alguna vez pasa de obsoleto a inválido , entonces todas esas asignaciones y documentación deben recortarse de una sola vez. Bueno, supongo que las asignaciones pueden permanecer en su lugar, aunque podrían hacer tropezar a los usuarios que no están atentos desde hace mucho tiempo.
  2. Hay plantillas que simplemente incorporan una plantilla de estilo CS1 precargada: por ejemplo, incrustar {{ Libro de citas}} como una cita en un volumen específico que sea relevante para cualquier uso de esta plantilla. ¿Se han arreglado todos? De lo contrario, su usuario verá un mensaje de error rojo (¿correcto?) Que no tiene nada que ver con su propio uso.
  3. Puede haber plantillas que se modelen en CS1 pero que desarrollen su propia expansión, aunque no conozco ninguna. Si se usan |authorlink=, ¿deberían también ponerse en línea?
Dos comentarios finales: hay más de seis, si se consideran variantes como |author1link=y |authorlink1=. Y, en principio, los argumentos anteriores se aplican a cualquier página fuera del espacio de plantilla que alguien transcluya, aunque sé que esa característica rara vez se usa. David Brooks ( charla ) 16:51, 12 de febrero de 2021 (UTC)
Debería haber dicho: lo anterior se aplica a A y, hasta cierto punto, a B, pero probablemente puedas averiguarlo. David Brooks ( charla ) 16:57, 12 de febrero de 2021 (UTC)
DavidBrooks : Hay un pequeño ejército de editores listos para arreglar estas plantillas. Hasta donde yo sé, no hay plantillas transferibles que pasen |authorlink=, su ejemplo, a cualquier plantilla de CS1, por lo que el uso de esas plantillas no generaría un mensaje de error. |accessdate=y el bot estaba procesando los dos o tres parámetros restantes sin guiones que se pasaban de las transclusiones de plantilla a las plantillas de CS1 antes de que se detuviera para mantener esta discusión. Una vez que se cierre esta discusión, el bot podrá reanudar ese trabajo, con ayuda humana, si el cierre es razonable. - Jonesey95 ( charla ) 17:13, 21 de febrero de 2021 (UTC)
@ Jonesey95 : Acabo de abordar un problema relacionado en Help talk: Citation Style 1 , donde al modificar el ejemplo dado encontré 3 plantillas que se usan |authorlink=en una plantilla de estilo CS1 que se usa para hacer referencia a una fuente específica: {{ Barmakids family tree }} , {{ Citeer web }}, {{ Alox2 }}. Pero esta consulta menos restrictiva muestra algunas más (ignore el archivo "DYK", creo). No estoy seguro de si se refería a este tipo de uso en su comentario; Puede que me esté perdiendo el contexto. David Brooks ( charla ) 05:05, 22 de febrero de 2021 (UTC)
@ Jonesey95 : OK, parece que arreglaste {{ Alox2 }}. {{ Árbol genealógico de Barmakids }} y {{ Citeer web }} aún deben arreglarse (lo haré más tarde hoy). La documentación de "Citar libro (breve)" en {{ Quicktemplates }} enumera lo que no es incorrecto |authorlink=, por lo que se incluye en la regla "preferir las formas de guión en la documentación". No busqué |authorlink2=o |author2link=porque es poco probable que aparezcan solos. David Brooks ( charla ) 19:17, 22 de febrero de 2021 (UTC) ... controlarY, también {{ las composiciones de Bach (fuentes) }}, que de hecho sí |author2link =. David Brooks ( hablar) 21:42, 22 de febrero de 2021 (UTC)
  • Me gustaría aclarar lo que quise decir cuando originalmente escribí las opciones, ya que existe cierta confusión. Mi intención con "eliminación" era referirme únicamente a la eliminación del uso de parámetros sin guiones mediante transclusiones de la plantilla, no a la eliminación de la implementación de la plantilla en sí (llamaré a esto "deshabilitar el parámetro"). Esto también es distinto de la desaprobación, que designa algo en la documentación y los mensajes de advertencia como desaconsejados. Recuerde que la razón original de este RfC es aclarar si deberíamos tener un bot recorriendo el espacio del artículo eliminando el uso del parámetro como su única acción. A, B y C se continúan eliminando ahora, respectivamente, se eliminan solo como parte de otras ediciones no cosméticas o en una situación en la que se permiten ediciones solo cosméticas, o no lo quite. En el caso de A o B, no tenía la intención de que hicieran una declaración sobre si deberíamos deshabilitar el parámetro cuando se hace esto. Esta es una pregunta importante, pero ortogonal a si el uso del parámetro se elimina ahora o más tarde. -  La  Tijereta  alt  ⟨ charla ⟩ 22:11 13 de febrero 2021 (UTC)
    Gracias por la aclaración (excepto la parte en que se formuló la opciones). Desafortunadamente, ahora significa que me falta la opción : los parámetros sin guiones deberían quedar obsoletos ahora y eliminarse más tarde . El status quo real parece ser: los parámetros sin guiones deben eliminarse ahora y desaprobarse más adelante , y la eliminación puede ocurrir mediante un bot que no hace nada más en la página (solo cosmético), pero volverá a visitar la página con la frecuencia necesaria para volver a -eliminar los parámetros no obsoletos que se siguen agregando. -  JohnFromPinckney ( charla ) 23:01, 13 de febrero de 2021 (UTC)
    Para el contexto, así es como lo expresé originalmente; las notas B y C se intercambian. ¿No es lo que desea exactamente la opción B (en la formulación actual)? Parece que describir a B como el "status quo" es confuso. En su lugar, vea A como lo que estaba haciendo el bot antes de que se detuviera, y B como lo que está sucediendo actualmente con el bot detenido, pero con una clara y formal desaprobación. -  La  Tijereta  alt  ⟨ charla ⟩ doce y diecinueve, 14 de Febrero 2021 (UTC)
    Mmm, tal vez, y en cualquier caso, estoy muy agradecido por su enlace a la coordinación previa a RfC en Primefac's Talk . Y puedo decir que su formulación original era más clara que la formulación que estamos usando ahora para el RfC propiamente dicho. Sin embargo:
    1. No parece haber consenso para la eliminación de parámetros de palabras múltiples sin guiones. El RfC de 2014 determinó solo que la versión con guiones debe existir, y el cierre permitido explícitamente para los que no lo son.
    2. Si este RfC está destinado a determinar si los elementos que no son guiones deben quedar obsoletos, está mal formulado en la medida en que menciona las actividades actuales del bot.
    3. No puedo ver la Opción A como lo que estaba haciendo el bot antes de que se detuviera , porque el parámetro no ha quedado obsoleto. (La declaración de Nikkimaria de que la desaprobación "en el contexto de CS1 / CS2" significa que se mostrará un mensaje de mantenimiento rojo no es algo que pueda aceptar, ya que cualquier proveedor de software razonable sabe que la notificación previa es la primera parte de la desaprobación. Desafortunadamente, yo no suele funcionar "en el contexto de CS1 / CS2", por lo que no he discutido antes esta infeliz definición).
    4. La opción B, como está escrita en esta página, es un lío confuso, no solo por la mención del "status quo", sino también por el bit "La desaprobación se puede agrupar en genfixes ...". La obsolescencia, como se indicó anteriormente, es (primero) una tarea de documentación, seguida de un paso (presumiblemente pequeño) para generar mensajes rojos (no estoy seguro de lo que está involucrado aquí). No veo lo que debería ser "empaquetado en genfixes". Tenía la sensación de que muchos de los votantes aquí veían la "eliminación" como la eliminación de usos, pero tal vez eso se deba a mi propia confusión. Su Opción C (y sus formulaciones originales en general) fueron mucho más claras.
    Nunca debería haber habido ninguna actividad de bot, porque (a) no hay consenso, todavía, para desaprobar los no guiones, (b) los parámetros aún no están desaprobados, y (c) las ediciones de los bots han sido en gran parte fecha de acceso => ​​acceso -sólo fecha, así que viola WP: COSMETICBOT . Así que supongo que estaré! Votación para B, aunque me gustaría mucho más bien elegir su opción original de C. Este RFC como está escrito ha sido demasiado claro (al menos para mí). -  JohnFromPinckney ( charla ) 11:20, 14 de febrero de 2021 (UTC)
    Re El RfC de 2014 determinó solo que la versión con guión debe existir : Como se indica en la propuesta, también dijo La documentación debe mostrar esta versión en minúscula y con guión como la de "uso normal" . De ahí mi comentario anterior: algunos de nosotros modificamos recientemente la documentación de algunas plantillas de alto uso para hacer que la versión con guiones sea la privilegiada, pero no puedo garantizar que obtengamos tanto / doc como TemplateData para cada plantilla que usa indirectamente CS1 / 2 . Si terminamos con guiones y sin guiones igualmente válidos (¿es eso C?), Entonces modificar la documentación será el único cambio visible para los editores actuales. ¿Debería haber un esfuerzo más valiente para rastrearlos a todos? David Brooks ( charla ) 19:45, 14 de febrero de 2021 (UTC)
    Si el consenso es para la Opción C, entonces nadie tiene que rastrear nada; podemos dejar la documentación como está. Por cierto, la afirmación escrita allí, esto también significará que la lista de parámetros obsoletos deberá actualizarse para eliminar los parámetros sin guiones es otra pista falsa y, al parecer, no se aplicaría en absoluto (ya que la fecha de acceso ni siquiera aparece en la lista Todavía ahí).
    Si elegimos las Opciones A o B, entonces sí, la documentación debe cambiarse inmediatamente. No puedo creer que se necesite demasiado valor para encontrar la documentación web de Template: Cite , ya que no parece terriblemente exótico, pero debería incluirse en los ajustes en esos casos. -  JohnFromPinckney ( charla ) 20:07, 14 de febrero de 2021 (UTC)
    • El RFC de 2014 contó con una participación de solo siete personas y fue hace seis o siete años. Es pacientemente absurdo actualizar la documentación con un cambio tan radical basado solo en eso, y tales cambios deberían revertirse en espera del resultado de una RFC más clara. Además, el RFC de 2014 indicó específicamente que nada se depreciaría, por lo que si confía en él como justificación para cualquier cambio, obviamente no se pueden depreciar las versiones sin guiones hasta que un nuevo RFC lo anule. - Aquillion ( charla ) 22:19, 15 de febrero de 2021 (UTC)
    Lea el resumen en la parte superior de esta sección de Discusión. Aquí está el resumen de ese resumen: Docenas de parámetros de varias palabras sin guiones han quedado obsoletos, se han eliminado de las páginas y luego se han eliminado de las plantillas de Estilo de cita 1 durante los últimos siete años. Solo quedan seis. Durante esos siete años, se han introducido muchos parámetros nuevos de varias palabras con guiones, sin alias sin guiones. En la actualidad, la situación es que los parámetros de varias palabras sin guiones son el estándar, y hay un poco más de trabajo por hacer para eliminar los últimos seis valores atípicos. Desafortunadamente, parece que muchos editores no han habilitado las configuraciones útiles "Expandir la lista de seguimiento para mostrar todos los cambios, no solo los más recientes" y "Agrupar los cambios por página en los cambios recientes y la lista de seguimiento".para que las ediciones de los bots se puedan ocultar sin perder visibilidad de las ediciones humanas incorrectas, por lo que la gente se queja de que un bot "obstruye" sus listas de seguimiento. -Jonesey95 ( conversación ) 23:59, 15 de febrero de 2021 (UTC)
    Sin embargo, nada de eso es relevante para el comentario de Aquillion en lo más mínimo. Que se haya utilizado un consenso endeble (en el mejor de los casos) para justificar la eliminación de la funcionalidad en el pasado no significa que esa eliminación fue algo bueno o que el bot edita (lo que obstruye tanto las listas de seguimiento como los historiales de páginas con ediciones innecesarias, ya sea que oculten otras ediciones). o no) debe continuar. De hecho, sospecho firmemente que habría soporte para volver a habilitar los parámetros ya eliminados. Thryduulf ( charla ) 00:27, 16 de febrero de 2021 (UTC)

Tenga en cuenta, amigos, que este bot es único ; puede estar procesando unos 2 o 3 millones de páginas, pero sigue siendo una única vez, es decir (a menos que se revierte) solo aparecerá UNA VEZ en el historial de cualquier artículo. Así que la idea de que está "obstruyendo" los historiales de las páginas es una pista falsa . Si le molesta que "obstruya" su lista de seguimiento, configure las opciones recomendadas por Jonesey95 y otros. De modo que esa objeción también se queda en el camino. Tenga en cuenta también que este bot termina el trabajo. Una vez hecho esto, eso es todo, no más bots que hagan este tipo de cambio. Con el cargo de que este bot es "disruptivo" o que de alguna manera está "eliminando la funcionalidad", no puedo hacer nada mejor que copiar la observación de Rexx anterior: "Una vez que hayamos estandarizado los parámetros con guiones, los futuros editores mirarán hacia atrás y pensarán en lo poco convincente y este tipo de debate es una pérdida de tiempo ". - NSH001 ( charla ) 19:30, 21 de febrero de 2021 (UTC)

Excepto que, no, eso es completamente inexacto. Considere la posibilidad de la lista de personas de la Universidad de Pensilvania . Cuando miro las últimas 500 ediciones , veo que Monkbot ha estado allí SIETE veces: aquí (21:07, 19 de octubre de 2020) y aquí (01:02, 28 de diciembre de 2020) y aquí (17:21, 14 Enero de 2021) y aquí (21:21, 16 de enero de 2021) y aquí (01:53, 18 de enero de 2021) y aquí (15:30, 18 de enero de 2021) y aquí (20:54, 30 de enero de 2021) . Si bien esa primera edición (de octubre) no hizo nada con|accessdate=, todos los demás lo hicieron, siempre que encontrara nuevas adiciones al artículo. Tenga en cuenta que la quinta y sexta ediciones se realizaron el mismo día .
Por lo general, no bloqueo las ediciones de bots de mi lista de seguimiento porque quiero saber qué está pasando con "mis" artículos, y los bots generalmente hacen un trabajo útil e interesante. Es solo que (para mí) la ráfaga repentina e imprevista de ediciones multitudinarias (sin hacer, al parecer , nada que realmente me interese) fue bastante irritante. La repetición en la Lista de personas de la Universidad de Pensilvania realmente me subió la presión arterial, y eso no está lejos de ser "perturbador" para mí. -  JohnFromPinckney ( charla ) 21:15, 21 de febrero de 2021 (UTC)
Hmm ... La edición de octubre es Monkbot 17 (no 18), por lo que no entra en el alcance de este RfC. La edición del 28 de diciembre es la aplicación principal de este bot. Eso deja 5 ediciones adicionales inesperadas (en su mayoría bastante pequeñas) por parte del bot. Todos son causados ​​por editores que agregan parámetros que no se ajustan al estándar canónico. Así que sí, debería haber matizado mi declaración al permitir esa posibilidad, lo siento. Es comprensible que esto suceda en ausencia de una clara desaprobación (hasta ahora) de la forma sin guiones. Quizás los editores en cuestión estén utilizando alguna herramienta generadora de citas que no genera la forma canónica, en cuyo caso la herramienta debería actualizarse. Sea lo que sea, eso refuerza el caso para desaprobar las formas no canónicas lo antes posible y para avanzar lo más rápido posible con la tarea principal. Es tarde,y me iré a la cama en breve. Comentará sobre el comentario intemperante de Phil Bidger a continuación en la mañana. -NSH001 ( conversación ) 00:06, 22 de febrero de 2021 (UTC)
No, el editor en cuestión está / estaba copiando / pegando lo que encontraron en los artículos que estaban viendo. (El usuario tampoco ha aprendido que las referencias van después de la puntuación, o que una referencia con nombre copiada de otro artículo podría no estar declarada en la página de destino, o que Wikipedia tiene una función de vista previa para permitir la comprobación de errores. No es que yo esté amargo.) De acuerdo, sin una desaprobación real, nadie sabe lo que se supone que debe usar o no usar, por lo que las listas de seguimiento se ven plagadas de repeticiones innecesarias. Y no puedo señalar a un usuario así la desaprobación o el consenso de no usar los formularios sin guiones, porque aún no hay ninguno. -  JohnFromPinckney ( hablar ) 00:21, 22 de febrero de 2021 (UTC)
Gracias por eso. Si es el caso de que los editores de esa página simplemente copien y peguen citas de la biografía original de la wiki, entonces es una buena noticia: el problema desaparecerá si simplemente se permite que el bot continúe y solucione el problema en los artículos fuente. No creo que sea cierto que no haya consenso para este cambio: el estilo deseado se estableció en un RfC hace varios años, y se ha implementado en un 90% en los años posteriores, sin objeciones sustanciales. De modo que existe un consenso efectivo y no tiene sentido no llevar la tarea hasta su conclusión lógica. Las objeciones aquí equivalen a una aversión por la aparición de un gran número de ediciones de bots en las listas de seguimiento, no por los méritos reales del caso. - NSH001 ( conversación ) 07:34, 22 de febrero de 2021 (UTC)
El RfC en cuestión solo tenía siete soportes, y solo se refería a asegurarse de que existía una versión con guiones y se presentara primero en la documentación. No sé cómo podría interpretarse eso como un consenso efectivo para desaprobar un parámetro que, antes de la ejecución del bot, parece haber sido más utilizado que la variante con guión, e incluso si pudiera, sería limitado . La objeción al bot no es solo que edita mucho, sino que "arregla" algo que no es un problema. Nikkimaria ( charla ) 14:01, 22 de febrero de 2021 (UTC)
Exactamente esto. -  JohnFromPinckney ( charla ) 02:05, 23 de febrero de 2021 (UTC)
Nikkimaria, la primera falacia en su argumento es que está asumiendo que la comunidad en general, si participara en el RfC original, no estaría de acuerdo con su conclusión. Ese no es (del todo) el caso; estoy bastante seguro de que, de las diversas opciones disponibles para parámetros de varias palabras (runon, camelCase, under_score, partición de palabras, etc.), la partición de palabras se seguiría eligiendo, simplemente porque es el más fácil de leer en wikitexto. Posiblemente, el guión bajo podría ser mejor (no se ajusta en línea) pero la mayoría de las personas, aparte quizás de aquellas con experiencia en programación, se sentirán mucho más cómodas con el guión, por lo que RfC llegó a una conclusión muy sensata. Sin embargo, el detalle de su implementación es otro asunto. La segunda falacia en su argumento se refiere al motivo de la objeción al bot. En primer lugar,el hecho observable es que algunos editores ahora están armando un gran escándalo por este bot, pero no dijeron nada sobre las muchas otras ejecuciones de bot para todos los demás parámetros de CS1 / 2 que hacen exactamente lo mismo. En segundo lugar, y también lo veo repetidamente en otras RfC, que los editores tienden a centrarse únicamente en un problema percibido a corto plazo, sin tener en cuenta el panorama general y el contexto más amplio. Ese contexto ya se ha descrito bien en la introducción de este RfC y en los enlaces que se proporcionan allí. Me sorprende que la gente no vea que el objetivo de este trabajo es hacer que las plantillas de citas sean más simples y fáciles de usar. Parte de ese proceso es hacer que los nombres de los parámetros sean más significativos y consistentes. Es ridículo dejar el desorden heredado de los primeros días de las plantillas de citas,con estos pocos parámetros restantes sobresaliendo como pulgares doloridos. -NSH001 ( conversación ) 08:25, 25 de febrero de 2021 (UTC)
Explique cómo permitir, por ejemplo, "fecha de acceso" es menos significativo, menos simple y más difícil de usar para los editores habituales. Ese es el panorama más amplio, el contexto más amplio: los beneficios son en realidad solo para un pequeño grupo de personas, que tienen todo el derecho a presentar su caso y preguntar si su vida puede ser más fácil, pero no deben sorprenderse cuando resulta que en algunos casos, su solución preferida no es compatible con el grupo más grande de personas que no hacen (o no con tanta regularidad) la plantilla y el bot. Poner mensajes de error en miles de páginas para cosas que no son un error, pero algo que algunas personas decidieron que ya no está permitido en absoluto, también está perdiendo de vista el panorama general. Fram ( charla ) 09:24, 25 de febrero de 2021 (UTC)
está asumiendo que la comunidad en general, si participara en el RfC original, no estaría de acuerdo con su conclusión . No lo sé, y tú tampoco, porque nunca se consultó a la comunidad en general . Nosotros podemos estar razonablemente seguros de que la discusión habría sido mucho menos unilateral, basado en el comentario posterior. En cuanto a la segunda mitad de su punto, como señala Fram, no está del todo claro por qué desaprobar los alias de uso generalizado haría que las plantillas sean más fáciles de usar para el editor promedio. Nikkimaria ( charla ) 13:33, 25 de febrero de 2021 (UTC)
(respondiendo a ambos). Sí, eso es fácil. Existe una regla muy simple para todas las plantillas de citas de CS1 / 2: todos los parámetros de varias palabras usan un guión para separar las palabras. Eso es. Muerto fácil de recordar. Además, ya está implementado para la gran mayoría de los parámetros (solo quedan 5 por hacer). No compro el argumento de que tener que escribir UN carácter adicional es una carga insoportable. La única objeción válida que puedo ver es que el bot puede inundar las listas de seguimiento, pero eso es temporal hasta que finalice la ejecución del bot. Así que mi más sentido pésame para aquellos que se sienten irritados (yo no, tengo más de 6.000 páginas en mi lista de seguimiento y el spam de bot no me molesta), pero la irritación será temporal. Si realmente le molesta, otros han mencionado una forma de configurar su lista de seguimiento para evitar el problema.- NSH001 ( hablar) 07:35, 8 de marzo de 2021 (UTC)
En las listas de seguimiento, consulte la nota #Vale la pena a continuación para ver una posible forma de reducir la "interrupción". Olvidé responder al punto de Fram sobre el contexto más amplio: estaba pensando en la convención general de nomenclatura y por qué el bot lo hace más fácil, pero la última contribución de Trappist a la sección de la encuesta explica también la consideración más amplia de que debemos considerar todos los -Wikipedias en inglés que han tomado prestadas nuestras plantillas / módulos CS1. - NSH001 ( conversación ) 10:40, 8 de marzo de 2021 (UTC)
Entonces, ¿la solución para la edición de un bot contra el consenso es que aquellos que se oponen a dejar de verlo? No podrías inventar estas cosas. Una vez más, esta es una maldita enciclopedia, no un lugar para que los técnicos dicten a los editores. Encuentre un patio de recreo en otro lugar o consiga un trabajo real y descubrirá que a las personas solo se les puede pagar por escribir programas si hacen lo que sus usuarios quieren que hagan. Phil Bridger ( charla ) 21:27, 21 de febrero de 2021 (UTC)
Phil, tu primera oración es falsa. Este bot fue aprobado por consenso, siguiendo procedimientos estándar. De hecho, su operador hizo todo lo posible para gritar desde los tejados que es un robot "cosmético". Ignoraré tu ataque personal intemperante e infundado. Finalmente, sobre la cuestión de las ediciones de bots y las listas de seguimiento, les remito a la contribución de Bilorv a las 11:34 del 13 de febrero anterior, que parece una buena solución (solo agregaré la advertencia de que aún no la he probado). - NSH001 ( conversación ) 08:25, 25 de febrero de 2021 (UTC)

Al leer algunos de los comentarios anteriores, me siento tentado de agregar una nueva propuesta aquí: cada editor que deliberadamente hace un cambio que agrega un mensaje de error a al menos 10,000 páginas es eliminado de su editor de plantillas . Excluyendo a los gatos escondidos, por supuesto, estos no son un problema; pero ninguna depreciación de ningún parámetro justifica tal interrupción del espacio principal para los lectores. Fram ( charla ) 08:30, 24 de febrero de 2021 (UTC)

Tres respuestas: en primer lugar, los mensajes de error que muestran las plantillas de CS1 se muestran por consenso, no por un solo editor. En segundo lugar, los mensajes de error, como los que se muestran en los artículos de Categoría: errores de CS1: parámetro no admitido , se muestran no porque un solo editor haya cambiado una plantilla, sino porque los editores individuales cometieron errores cuando utilizaron plantillas de CS1. En tercer lugar, la objeción a que los mensajes de error se esparzan por el espacio del artículo es la razón por la que el bot estaba funcionando antes de que se mostraran los mensajes de error de obsolescencia . La gente odia la visualización de cientos de miles de mensajes de error menores, por lo que el bot estaba arreglando los artículos antes de que se cambiaran los módulos de CS1 para mostrar errores de parámetros obsoletos.
Sin embargo, la oferta de comentarios de Fram da algo en qué pensar; Si las opciones lógicas A o B se eligen aquí para que se pueda completar el último 10% de la separación de palabras de los parámetros CS1 de varias palabras, tal vez no deberíamos mostrar mensajes de error de parámetros obsoletos (excepto tal vez en el modo de vista previa) en los artículos hasta que el La gran mayoría de reemplazos de nombres de parámetros están completos. - Jonesey95 ( charla ) 16:29, 24 de febrero de 2021 (UTC)
Gracias, pero recuerde Wikipedia: Tablón de anuncios de administradores / Archive313 # ¿Existe una herramienta semiautomatizada que pueda corregir estos molestos errores de "Cite Web"? desde hace 1 año y medio? También hubo "consenso" para ese cambio, entre un pequeño grupo de editores, pero sin tener en cuenta a la comunidad en general. Esperaba que ese episodio hubiera aprendido a algunas de las personas más activas en estas plantillas que, cuando proponen un cambio que afecta a muchas páginas (y ciertamente cuando proponen un cambio agregando mensajes de error a muchas páginas), deberían obtener un consenso mucho más amplio. primero. Aún así, veo en la discusión anterior personas que argumentan para activar los mensajes de error rojos para esto (la mayoría de los mensajes de error que recibimos ahora están en muy pocas páginas o por errores reales, por ejemplo, fechas imposibles), lo cual no es un error, sino algo que a algunos operadores de bots y creadores de plantillas no les gusta. Fram ( charla ) 17:06, 24 de febrero de 2021 (UTC)
  • Tres respuestas: en primer lugar, los mensajes de error que muestran las plantillas de CS1 se muestran por consenso, no por un solo editor. Una cosa que esta discusión ha dejado muy clara, creo, es que muchos de los "consensos" utilizados para hacer cambios radicales como este no son ni remotamente suficientes en términos de escala según WP: LOCALCONSENSUS ; de nuevo, si lo fueran, no estaríamos teniendo esta conversación. Si desea realizar un cambio que afecte significativamente a cientos de miles de páginas, debe necesitar un consenso que involucre a una gran cantidad de usuarios, y debe transmitirse adecuadamente en foros de alto tráfico: un "consenso" de siete personas es pacientemente insuficiente para un cambio a esta escala, y dar la vuelta y usar bots o mensajes de plantilla para luego tratar de hacer cumplir esto equivale aWP: FAITACCOMPLI . - Aquillion ( charla ) 10:03, 4 de marzo de 2021 (UTC)
Esto no es una buena idea. En algunos casos, muchas plantillas se utilizan por error, aunque anteriormente no detectaban tales errores. Detectar y corregir tales errores es algo bueno. IAR es una política, y si alguien está rompiendo toneladas de cosas, por supuesto, elimine sus derechos, pero simplemente mostrar mensajes de error no es un problema claro.
En cuanto a la desaprobación de parámetros no silenciosos, sí, reemplace primero y luego desaproveche. No creo que nadie esté en desacuerdo con esto. Elliot321 ( charla | contribuciones ) 20:30, 3 de marzo de 2021 (UTC)
Bueno, ciertamente no estoy de acuerdo (y ya lo he hecho varias veces en esta página). Si hay consenso para eliminar ciertos parámetros, entonces lo primero que debe hacer es desaprobarlos, es decir , decirles a todos que no los usen más, luego, ejecutar los bots para reemplazar el uso y, finalmente, mostrar los mensajes rojos. y, en última instancia, eliminar por completo la compatibilidad con los parámetros obsoletos. Cualquier otro camino es una locura. -  JohnFromPinckney ( charla ) 03:54, 4 de marzo de 2021 (UTC)
  • Una de las objeciones que le planteé a Monkbot18 que no se aborda en absoluto en el argumento del "status quo" (opción A) es que el bot también realiza otros cambios, incluida la eliminación de espacios en blanco y saltos de línea de las plantillas de citas. Esto es inaceptable según MOS: STYLERET . En mi opinión, el tiempo que he dedicado a deshacer estos cambios en los artículos en los que me centro ha sido una carga mucho mayor que la falta o la presencia de un guión en un parámetro. Si este bot tiene la tarea de intercambiar parámetros, SÓLO debería cambiar "fecha de acceso" a "fecha de acceso" (y vis a vis guiones de parámetros similares), y absolutamente nadafuera de eso. La opción A no debe interpretarse como la aprobación del código del bot tal como está escrito actualmente, sino como la tarea para la que se suponía que debía cumplir. - Floydian  τ ¢ 18:33, 7 de marzo de 2021 (UTC)
    Bueno, eso es muy extraño, porque Monkbot18 tiene mucho cuidado de preservar los espacios en blanco (con una excepción muy razonable), así que no veo cómo va contra STYLERET. Es cierto que elimina los parámetros vacíos / en blanco, pero eso es bueno, ya que reduce el desorden en el wikitexto. También hace algunas otras cosas buenas, consulte Usuario: Monkbot / task_18: limpieza de plantilla cosmética cs1 . ¿Puede dar ejemplos específicos de ediciones que cree que están haciendo mal, por favor? - NSH001 ( conversación ) 19:13, 7 de marzo de 2021 (UTC)
    Hay una buena lista de reversiones si miras mis ediciones del 17 de enero, pero aquí tienes un ejemplo . - Floydian  τ ¢ 06:27, 8 de marzo de 2021 (UTC)
    Ah, esa es la "única excepción muy razonable" a la que me referí. Todos los demás cambios que creías que debías hacer en tu "limpieza y estandarización de las primeras 150 referencias. Revierte al estúpido friggen MonkBot haciendo cambios de estilo en miles de artículos en un" consenso "de como 3 personas, y evita que se realicen más ediciones". la edición depende de otros editores / bots, no de Monkbot18. Creo que una línea en blanco dentro de una plantilla de cita siempre es innecesaria y ocupa un espacio valioso dentro de la ventana de edición, pero si te molesta tanto, siempre puedes preguntarle a Trappist amablemente, y estoy seguro de que eliminará ese ajuste por usted. - NSH001 ( conversación ) 07:15, 8 de marzo de 2021 (UTC)
    En ese caso, su millaje puede variar y se aplica STYLERET. Las líneas en blanco facilitan la selección de citas del texto y las barras de desplazamiento superan el argumento del "espacio valioso". Traté de pedir que se eliminara ese comportamiento. Me encontré con (* parafraseado) "se aprobó el código del bot, procediendo". Así que bloqueé el maldito bot de los 300 artículos en los que trabajo. Ahora bien, si alguien está tan preocupado por un guión en un parámetro, que pueden ir a cambiar manualmente. Simple como eso.
    O, ya sabes, el bot podría limitarse a realizar los cambios en los parámetros que se supone que debe hacer . No debería necesitar preguntar, no es parte del mandato del bot , elimínelo. - Floydian  τ ¢ 15:43, 8 de marzo de 2021 (UTC)
    Primero, dice que traté de pedir que se eliminara ese comportamiento. Me encontré con (* parafraseado) "se aprobó el código del bot, procediendo" . Eso es sorprendente, ya que esperaría que Trappist esté dispuesto a aceptar tal solicitud (es importante hacer este trabajo, por lo que vale la pena hacer un pequeño cambio como este para evitar retrocesos). ¿Puede indicarme la conversación en la que hizo esta solicitud y recibió esa respuesta, por favor?
    (más tarde) - ah, no te molestes - lo encontré yo mismo Charla de usuario: Trapense el monje / Archivo 17 # Tarea 18 eliminando el espacio de referencia . Parece que no le explicaste muy bien a Trappist. FWIW, puedo ver la justificación de la línea en blanco para las citas en línea dentro del cuerpo del artículo, si impide que las personas lo conviertan en el (horrible) formato horizontal. Toco esto nuevamente a continuación, pero estoy de acuerdo con usted en que Monkbot18 no debería eliminar la línea en blanco. (Espero que Trappist esté leyendo esto). Pero el resto de los cambios que está haciendo son buenos y deberían permanecer. (En realidad, para ser estrictamente correcto, Monkbot debería eliminarlo dentro de LDR o listados bibliográficos, pero no dentro del cuerpo principal. Para simplificar, diría que simplemente no se moleste en intentar eliminarlo).
    En segundo lugar, o, ya sabes, el bot podría limitarse a realizar los cambios en los parámetros que se supone que debe hacer . Esa afirmación es falsa. El bot fue aprobado para realizar las tareas enumeradas en el enlace que ya he proporcionado: Usuario: Monkbot / task_18: limpieza de plantilla cosmética cs1 , y eso es exactamente lo que ha estado haciendo el bot. Aparte del problema de la línea en blanco, los otros cambios son buenos y valiosos, y reducirán la necesidad de ejecutar más bots en el futuro. Una de las razones por las que me gusta tanto este bot.
    El siguiente fragmento es muy interesante (para mí) pero se desvía principalmente del tema, así que lo voy a poner en un texto pequeño. Si desea llevarlo más lejos, no dude en discutirlo en mi página de discusión. El problema del desorden de citas en el cuerpo principal de los artículos de Wikipedia me ha estado molestando durante años, y especialmente los enormes problemas causados ​​por las plantillas de citas largas con formato horizontal, que en mi opinión hacen que el wikitexto sea difícil o imposible de leer y editar. Todo esto se establece en un "hilo" muy largo (en realidad ya no es un hilo): en mi página de discusión. Se trata de una forma de establecer plantillas de citas que llamo "ETVP" por "fácil de analizar visualmente", que es similar en muchos aspectos a las citas en su ejemplo, pero también difiere en algunos aspectos. El punto interesante que mencionar aquí es que tuve una experiencia difícil y dolorosa al tratar de introducir citas con formato ETVP en los cuerpos de los artículos. La excusa ofrecida para revertirme fue principalmente "ocupa demasiadas líneas" en el cuadro de edición (de ahí "la única excepción muy razonable" anterior), así que al final me di por vencido y me centré principalmente en otras soluciones (ETVP dentro de WP: LDR o ETVP dentro de listados bibliográficos utilizando referencias de formato corto) que en la mayoría de los casos son una mejor solución de todos modos. Eso'Una paradoja fascinante es que parece que se ha salido con la suya utilizando máslíneas, no menos, combinadas con un uso generoso del espacio en blanco, exactamente lo contrario de lo que cabría esperar. Así que ahora estoy pensando en agregar una opción similar a mi script ETVP, y gracias por suscitar ese pensamiento. Sin embargo, necesitará pensarlo un poco.
    - NSH001 ( conversación ) 10:02, 9 de marzo de 2021 (UTC)

Vale la pena señalar [ editar ]

Trappist ha presentado amablemente, muy claramente, una sugerencia sobre cómo configurar su lista de seguimiento para evitar los problemas de un gran número de ediciones de bots en las listas de seguimiento. Lo copio aquí, en caso de que sea útil para alguien:

  • en Especial: Preferencias # mw-prefsection-watchlist :
    • marque Opciones avanzadas → Amplíe la lista de seguimiento para mostrar todos los cambios, no solo los más recientes
    • comprobar los cambios mostrados → Ocultar las ediciones del bot de la lista de seguimiento
  • en Especial: Preferencias # mw-prefsection-rc :
    • comprobar Opciones avanzadas → Agrupar cambios por página en cambios recientes y lista de seguimiento

Tenga en cuenta que (todavía) no lo he probado yo mismo, ya que estoy satisfecho con la forma en que está configurada mi lista de seguimiento. - NSH001 ( conversación ) 09:09, 8 de marzo de 2021 (UTC)

Nota para RFC más cercano: las instrucciones anteriores son un remedio para todas las personas que apoyan la Opción C debido a la "obstrucción de la lista de seguimiento" y los supuestos problemas que las ediciones del bot causan a los editores que están atentos al vandalismo. Por lo que puedo decir, ningún editor que use la configuración anterior se opone a los cambios del bot en función de los problemas de la lista de observación. A menos que se presente una objeción válida, propongo que se descarte todo el apoyo de la Opción C que cite los problemas de la lista de vigilancia y se oriente a la recomendación anterior. - Jonesey95 ( charla ) 17:30, 8 de marzo de 2021 (UTC)
Esta es una solución que (a) no debería ser necesaria, (b) no funciona para todos, por ejemplo, aquellos que quieren ver ediciones de bot (yo sí, por ejemplo) y (c) no soluciona el problema solo como un síntoma . Además, es muy inapropiado sugerir que se descarta un gran número de preferencias válidas y racionalmente expresadas por el editor. Thryduulf ( conversación ) 17:41, 8 de marzo de 2021 (UTC)
He estado probando esta solución durante el último día más o menos. En diciembre, limpié mi lista de seguimiento y tomé una wikibreak de dos meses y medio mientras el bot funcionaba. Acabo de regresar a Wiki y descubrí que el bot ha sido detenido, pero pensé en probar la sugerencia de Trappist. Hasta ahora todo bien, es un poco diferente, ¡pero al menos hace que la lista de observación sea más cuerda que durante el ataque del bot! Martin of Sheffield ( charla ) 20:23, 8 de marzo de 2021 (UTC)

RfC: deshabilitar ediciones menores en Wikipedia en inglés [ editar ]

Propuesto: Desactive efectivamente la funcionalidad de "ediciones menores" en la Wikipedia en inglés. Su uso estará limitado por la política de reversión antivandálica únicamente. Técnicamente, el permiso para marcar como menor se limitará a rollbackers, administradores y bots. ProcrastinationReader ( charla ) 19:56, 15 de febrero de 2021 (UTC)


Encuesta (ediciones menores) [ editar ]

  • Soporte Aparentemente, el punto es que algunos editores ignoren las ediciones "m" en las listas de seguimiento. Ningún editor experimentado lo haría porque las ediciones "m" pueden ser tan erróneas, perturbadoras o destructivas como una edición "importante". Los vándalos pueden usarlos para actos de vandalismo, los editores novatos de buena fe con cambios problemáticos y los editores experimentados pueden hacer algo que creen que es menor pero otros editores no están de acuerdo. Realmente, todas las ediciones están sujetas a disputa. El objetivo de una lista de seguimiento es monitorear los artículos . Es más, aparentemente bloqueamos a los editores por problemas menores relacionados con ediciones. La funcionalidad no solo es inútil, es netamente negativa. Las ediciones menores se pueden comunicar a través del resumen de la edición y el recuento de diferencias.ProcrastinationReader ( hablar) 19:56, 15 de febrero de 2021 (UTC)
  • Oponerse . Marco las ediciones como menores todo el tiempo cuando son, de hecho, menores. Corregir errores tipográficos y cosas por el estilo no tiene por qué molestar a los editores que no quieren ver esas ediciones. Si hay un problema con las ediciones que no son menores y que se marcan como menores, averigüe cómo resolverlas. Ya marcamos, por ejemplo, posibles cambios en las fechas de nacimiento y defunción. BD2412 T 20:03, 15 de febrero de 2021 (UTC)
    • Nota : Apoyo las siguientes propuestas para limitar las ediciones menores a editores confirmados autoconfirmados o extendidos (preferiblemente los últimos). BD2412 T 04:56, 3 de marzo de 2021 (UTC)
  • Oponerse a una política según la cual el menor debe ser solo para la reversión del vandalismo; Estoy de acuerdo con BD2412 en que acciones tales como pequeñas correcciones de errores tipográficos, pequeños ajustes de espacios en blanco, etc., deberían calificar como "menores" para propósitos de patrullaje y revisión. Nuetral en un componente superpuesto de esto, la eliminación del minoreditpermiso de "Todos los usuarios", si los usuarios más nuevos lo utilizan con frecuencia, podría ser útil, pero si es así, creo que debería ir a + extendedconfirmed y / u otros grupos (es decir rollbacker / patroller) que de otra manera ayudan a reconocer que un editor tiene un mínimo de experiencia aquí. - Charla xaosflux 20:23, 15 de febrero de 2021 (UTC)
    • Un caso de uso perfectamente cromulento es el de un bot que tiene que hacer una limpieza sin contenido en las páginas de conversación del usuario, declarando que la edición es menor y aprovechando su nominornewtalkpermiso; el operador puede evitar molestar a los usuarios con una notificación de mensajes nuevos. Si bien los "bots" estaban en la propuesta original, este caso de uso no cumple con los criterios de "solo reversión antivandálica". - Charla xaosflux 20:41, 15 de febrero de 2021 (UTC)
      Para mayor claridad, me refiero al anti-vandalismo solo para editores humanos (los bots pueden usarlo como lo hacen). ProcrastinationReader ( charla ) 20:44, 15 de febrero de 2021 (UTC)
      @ ProcrastinationReader : OK, gracias, cualquier uso de bot ya debería estar gobernado por un WP: BRFA específico para lo que sea que estén haciendo (y esto casi siempre se usa además de la bandera 'b'ot). - Charla xaosflux 20:52, 15 de febrero de 2021 (UTC)
      Re typos, una corrección de errores tipográficos todavía se puede disputar. Quizás el editor se equivocó y el 'error tipográfico' fue intencional. Más importante aún, el comentario de Suffusion of Yellow, especialmente sobre la parte malvada , es una buena manera de expresar el problema en mi opinión. Mientras algunas ediciones en disputa puedan fluir a través de él, toda la función no tiene valor. La asignación antivandálica se debe a que ya se rige por la política existente, WP: ROLLBACKUSE y WP: VAND , etc., y permite filtrar la 'basura' pura. Aunque también estoy de acuerdo con eliminar esta exención. ProcrastinationReader ( charla ) 20:55, 15 de febrero de 2021 (UTC)
  • Soporte . Mientras esta función esté disponible para spammers, vándalos y los despistados, es tan inútil como el mal . También es una fuente de drama innecesario, cuando los usuarios lo abusan inocentemente. Pero si la gente piensa que esta propuesta va demasiado lejos, limitarla extendedconfirmedsería un buen comienzo. Suffusion of Yellow ( charla ) 20:33, 15 de febrero de 2021 (UTC)
  • Oponerse ¿Por qué? Mike Peel ( charla ) 20:35, 15 de febrero de 2021 (UTC)
  • Admite , tentativamente, deshabilitar la opción al realizar una edición manual. Simplemente no es tan útil; incluso los usuarios experimentados no están de acuerdo con lo que significa y no lo usan de manera constante. El recuento de bytes es una forma mucho más eficaz de identificar cambios "menores" de un vistazo, ya que es menos propenso a la manipulación. Debido a que la marca menor se puede configurar de manera inapropiada, casi nunca es razonable filtrar completamente las ediciones menores, por lo que simplemente actúa como una señal débil de intención en los historiales de la página, redundante para editar el resumen y el recuento de bytes. Sin embargo, no estoy convencido de que sea solo antivandalismo. -  La  Tijereta  ⟨ charla ⟩ 20:37, 15 de Febrero 2021 (UTC)
    Después de leer los comentarios en oposición y considerar soluciones alternativas para el problema, no creo que esta propuesta tal como está escrita sea el camino a seguir. -  La  Tijereta  ⟨ charla ⟩ 19:13 16 de febrero 2021 (UTC)
    Soporte de limitación a autoconfirmado como primer paso. Oponerse a limitar a extendido confirmado. Entiendo los argumentos a favor, pero en general me opongo a expandir el papel de EC quitando privilegios a los usuarios autoconfirmados (otorgar privilegios a los usuarios de EC de otra manera solo disponibles para usuarios más restringidos es otra cosa). Incluso con esto, no pudimos evitar todos los errores de ediciones como menores, ni deberíamos esforzarnos por hacerlo. La mayoría de las ediciones menores etiquetadas por alguien con, digamos, 2 meses de experiencia y 100 ediciones estarán bien, y si no lo son, es probable que no se den cuenta en la edición número 500. -  The  Earwig  ( charla ) 06:46, 3 de marzo de 2021 (UTC)
  • Oponerse como está escrito. Podría tener sentido limitar aún más quién puede marcar las ediciones como menores, pero eliminarlas casi al por mayor como lo hace esta propuesta va demasiado lejos. Esto es usar un destructor de búnkeres para acabar con algunos avispones. - Calidum 21:11, 15 de febrero de 2021 (UTC)
  • Apoye la idea de deshabilitar la opción de marcar las ediciones como menores al editar manualmente. Realmente no veo el sentido de hacer solo el CV de la bandera 'menor', o otorgárselo a administradores o rollbackers. Si creemos que es inútil, entonces lo desaprovechemos por completo, en lugar de intentar debatir quién tiene la experiencia suficiente para usarlo. El único uso realmente claro para las ediciones menores es que los bots editen las páginas de conversación de los usuarios, como Xaosflux dijo sabiamente anteriormente, por lo que los bots obviamente deberían conservar el derecho por esa razón. Las ediciones de los bots ya se pueden filtrar de las listas de seguimiento, por lo que, salvo en las páginas de discusión de los usuarios, no importa si las ediciones de los bots son menores o no. ƒirefly ( t · c ) 21:35, 15 de febrero de 2021 (UTC)
    Otros usos de ediciones menores incluyen (pero no se limitan a):
    • Correcciones ortográficas
    • Correcciones de capitalización
    • Correcciones de errores tipográficos
    • Correcciones gramaticales
    • correcciones en negrita / cursiva
    • Correcciones de orden de lista
    • Correcciones de marcado (plantillas, tablas, etc.)
    • Pequeñas correcciones a los comentarios (por ejemplo, faltan palabras)
    • Firma de comentarios sin firmar
    • Correcciones de espacios en blanco
    • Adición de plantillas que tienen un impacto mínimo o nulo en el contenido (p. Ej., {{ A partir de }}, {{ Actualizar después }}, {{ convertir }})
    • Ajuste de enlaces
    • Agregar / ajustar notas de sombrero
    • Protección / desprotección de páginas (marcadas automáticamente como menores). Thryduulf ( conversación ) 21:53, 15 de febrero de 2021 (UTC)
  • Oposición muy fuerte . Hay (probablemente) un problema que debe resolverse detrás de esta propuesta, pero no hay evidencia presentada de que (a) el problema sea generalizado (es decir, que la solución radica en algo más que educar y / o bloquear a los usuarios individuales), ( b) restringir las ediciones menores resolverá el problema subyacente, (c) que restringir las ediciones menores tanto como se proponga es necesario o proporcionado, o (d) que el daño colateral inevitable causará menos problemas y menos significativos que el original. Por lo tanto, es demasiado, demasiado prematuro llevar esto a esta junta, y mucho menos a un RfC; claramente, no se ha pensado rápidamente, y mucho menos repetidamente, de manera completa y en profundidad. Thryduulf ( conversación ) 21:37, 15 de febrero de 2021 (UTC)
    Claramente, no se ha pensado rápidamente, y mucho menos repetidamente, de manera completa y en profundidad . He discutido esto con otros editores en múltiples AN / ANI el pasado y este año, y esto vino directamente de un VPT de esta semana. Entonces eso no es cierto. ProcrastinationReader ( charla ) 22:26, ​​15 de febrero de 2021 (UTC)
    Esto es vago y ausente en muchos sentidos. Estoy realmente atónito de que varios editores pensaran que esta era una propuesta viable. Thryduulf ( charla ) 23:02, 15 de febrero de 2021 (UTC)
  • Oponerse . Los editores más experimentados usan mucho el menor cuando realizan correcciones de errores tipográficos totalmente incontrovertibles, cambios de formato menores, wikificar y cosas por el estilo. Esto se siente como una situación de baño de bebé. Espresso Addict ( charla ) 00:36, 16 de febrero de 2021 (UTC)
    La cosa es que para que algunas personas obtengan algún beneficio al ignorar las ediciones marcadas como menores, otras deben continuar monitoreando todas las ediciones. En la actualidad, es como si algunas personas simplemente jugaran con el bebé sin turnarse para ocuparse del agua de la bañera. Lo cual está bien cuando hay suficientes personas que no filtran las ediciones menores, pero significa que el filtrado de las ediciones menores intrínsecamente no se amplía, y eso me incomoda promocionar sus beneficios para todos. isaacl ( charla ) 00:59, 16 de febrero de 2021 (UTC)
    Creo que estamos hablando de cosas ligeramente diferentes aquí. Lo veo como una señal de un editor experimentado a un editor experimentado que no dice nada que ver aquí, lo que parece inequívocamente útil. Usted, creo, se está quejando de que los editores que filtran ediciones menores en las listas de seguimiento (o, como yo, no se molestan en absoluto con una lista de seguimiento) están imponiendo la carga a otros para que las revisen. Eso parece más un problema en la forma en que se configuran las listas de seguimiento, que en el principio de que las ediciones se marcan como menores / no. ¿Quizás se podría diseñar un filtro de edición para marcar las ediciones que claramente no son menores y eliminar la designación? Espresso Addict ( charla ) 02:02, 16 de febrero de 2021 (UTC)
    Lamentablemente, la señal no es confiable. Es un problema de inteligencia artificial detectar automáticamente ediciones menores. Si funciona lo suficientemente bien, entonces no habría necesidad de marcar manualmente. Esa podría ser una buena idea, pero no estoy seguro de si se le debe dar prioridad sobre otras tareas del desarrollador, particularmente dada la probable alta relación esfuerzo-beneficio. (Aprecio la ventaja de la señal, cuando es precisa, y he escrito sobre ella en la sección de discusión). Isaacl ( charla ) 03:13, 16 de febrero de 2021 (UTC)
    No me opondría enérgicamente a restringir la capacidad de marcar ediciones como menores a, digamos, editores confirmados extendidos; o más útil, dejar que los editores sin experiencia sigan marcándolos (para que aprendan a hacerlo según las normas de la comunidad), pero ignorando la marca (de los editores sin experiencia) en las presentaciones de listas de seguimiento. No creo que la IA vaya a diferenciarlos con la suficiente precisión en el corto plazo. Espresso Addict ( charla ) 03:48, 16 de febrero de 2021 (UTC)
    Ya tiene la capacidad de filtrar en función de la experiencia y las ediciones menores (así como una predicción de la calidad de la contribución), pero no creo que se pueda configurar para todas las ediciones de editores sin experiencia más las ediciones no menores de editores experimentados. El problema de confiabilidad permanece, incluso con editores experimentados, por lo que alguien debería estar revisando todas las ediciones menores. isaacl ( charla ) 04:06, 16 de febrero de 2021 (UTC)
  • Se oponen, pero están abiertos a reformas . La designación de edición menor es una pieza de información, al igual que el resumen de edición, que debe tomarse en contexto. Cuando veo una "m" junto a un nombre de usuario de buena reputación, eso me ahorra el esfuerzo de revisar la edición. Cuando está al lado de una edición gigante de una IPun usuario de enlace rojo con un resumen sospechoso, eso es diferente. Por esa razón, no los filtro de mi lista de seguimiento, pero si alguien más quiere hacerlo, puede hacerlo. Dicho esto, estoy de acuerdo en que el mal uso del cuadro de edición menor es un problema. Aquí hay una propuesta más modesta: limítelo a editores autoconfirmados, y la primera vez que alguien lo revise, haga que el software genere una ventana emergente que explique rápidamente lo que queremos decir con "menor". Con eso, podríamos adoptar una postura más dura sobre el uso indebido de la caja, ya que nadie podría afirmar que simplemente no lo sabía. Eso podría acercarnos a un punto en el que más editores se sientan cómodos filtrando ediciones menores de su lista de seguimiento. {{u | Sdkb }}  charla 07:19, 16 de febrero de 2021 (UTC)
    @ Sdkb : a menos que me falte algo, las IP no pueden etiquetar las ediciones como menores hoy (señale cualquier diferencia si puede ver una). Los usuarios no confirmados pueden, por lo que el siguiente "pequeño paso" sería eliminar ese acceso de "Todos los usuarios" y dárselo a los usuarios "confirmados automáticamente". - Charla xaosflux 14:30, 16 de febrero de 2021 (UTC)
    Estás en lo correcto; He arreglado mi hipotética. {{u | Sdkb }}  charla 18:34, 16 de febrero de 2021 (UTC)
    @ Sdkb : esos son los dos pasos que puedo admitir, junto con quizás un límite de bytes para que el tamaño de un cambio aún se marque como menor. BD2412 T 17:57, 16 de febrero de 2021 (UTC)
    Un límite de bytes puede ser complicado; Revertir un vándalo que borró una página es una edición menor muy válida, ya que claramente no es controvertida. Como alternativa, ¿tal vez rechazarlo si ORES lo marca como posiblemente no constructivo? {{u | Sdkb }}  charla 18:38, 16 de febrero de 2021 (UTC)
    Algo así definitivamente sería útil, sí. BD2412 T 00:20, 17 de febrero de 2021 (UTC)
  • Soporte La casilla de verificación agrega complejidad al proceso de hacer cada edición, con muy poco beneficio para otros editores y solo un poco de ansiedad por tal vez equivocarse. En promedio, supongo que dedico de medio segundo a un segundo a esta decisión cada vez. Haciendo los cálculos, eso suma de 2 a 4 semanas laborales de mi vida durante la última década. - Juan de Reading ( charla ) 08:28, 16 de febrero de 2021 (UTC)
    @ John of Reading : si le molesta personalmente, puede agregar esta línea a su Special: MyPage / common.css y ya no tendrá que ver ese cuadro:
    # mw-editpage-minoredit  { display :  none ;}
    - Charla xaosflux 19:57, 16 de febrero de 2021 (UTC)
    @ Xaosflux : La casilla de verificación que más utilizo es la de AWB, no la de la ventana de edición. Pero si oculto la casilla de verificación, o la dejo siempre sin marcar, y otros editores piensan que la distinción es importante, no les señalaré correctamente que la mayoría de mis ediciones son menores. - John of Reading ( charla ) 20:09, 16 de febrero de 2021 (UTC)
  • Fuerte oposición como innecesaria y contra-útil. Un gran porcentaje de mis propias ediciones son menores y me gusta la capacidad de mantener los grupos separados (aunque solo sea para mí). No hay razón para que otras personas tengan que estudiar detenidamente mis ediciones cuando todo lo que hice fue corregir la ortografía o corregir los formatos de fecha o eliminar los espacios antes <ref>, etc. -  JohnFromPinckney ( charla ) 18:11, 16 de febrero de 2021 (UTC)
  • Soporte para limitar la marca de verificación de "edición menor" a usuarios experimentados. Es muy poco confiable cuando lo usan los novatos. - Vis M ( conversación ) 21:04, 16 de febrero de 2021 (UTC)
  • Oponerse Una supuesta reversión del vandalismo no es necesariamente menor. Y el hecho de que la bandera no sea precisa es como todo lo demás en Wikpiedia. Cada página, edición, resumen o lo que sea podría no ser exacto. Según el descargo de responsabilidad, "WIKIPEDIA NO GARANTIZA SU VALIDEZ". Andrew 🐉 ( charla ) 23:12, 16 de febrero de 2021 (UTC)
  • Oponerse según BD2412 y xaosflux. Si bien estoy dispuesto a impedir que los editores no confirmados automáticamente marquen las ediciones como "menores", no estoy de acuerdo con la mayor parte de la propuesta. Sdrqaz ( charla ) 20:42, 18 de febrero de 2021 (UTC)
  • Límite a autoconfirmado Cualquier daño potencial por el mal uso de la bandera de edición menor es mínimo --- a la par con mover una página. Se necesita tiempo para descubrir qué es menor y qué no, y ya restringimos las direcciones IP. Si bien ciertamente podemos mejorar nuestra guía sobre el uso de la marca de edición menor, el nivel de amenaza no justifica restringir a los editores autoconfirmados en quienes ya confiamos con herramientas mucho más poderosas en sus manos. - Wug · a · po · des 22:31, 18 de Febrero 2021 (UTC)
  • Límite a autoconfirmado . Ya evitamos que las IP utilicen la caja, y se puede suponer que los nuevos usuarios no tienen experiencia de manera similar. Sin embargo, definitivamente es útil para exconf +, y dado que es, bueno, una característica menor, autoconf también debería tener acceso a ella. Estaría abierto a la idea de Sdkb de tener una ventana emergente la primera vez que alguien marca la casilla, aunque no estoy seguro de la viabilidad de esto en el extremo del software. - codificador de Python  ( charla  |  contribuciones ) 19:54, 19 de febrero de 2021 (UTC)
  • Nein : las ediciones menores son ediciones que, bueno, son menores. Si los marcamos como ediciones importantes, solo hará que los editores pierdan más tiempo en el backlog de la patrulla RC. - Comentario anterior sin firmar agregado por Awesome Aasim ( charla • contribuciones ) 03:15, 21 de febrero de 2021 (UTC)
  • Límite a autoconfirmado . Para los usuarios experimentados, especialmente cuando se trabaja con otros editores, esta es una señal importante. Cualquiera que no confíe en la marca de edición menor aún puede ver todas las ediciones, entonces, ¿por qué podría ser necesario eliminar esta funcionalidad? ThoughtIdRetired ( hablar ) 15:07, 21 de febrero de 2021 (UTC)
  • Me opongo firmemente a la idea propuesta, pero estoy de acuerdo con Pythoncoder (este es el segundo RfC de hoy en el que estoy de acuerdo con él) en que limitarlo a autoconfirmado es una buena idea. JJP ... ¡MAESTRO! [hablar con] JJP ... maestro? 01:55, 22 de febrero de 2021 (UTC)
  • Soporte con comentarios : (1) Los administradores deben poder marcar cualquiera de sus ediciones, relacionadas con el vandalismo o no, como "menor" si lo consideran beneficioso para la comunidad. Para el resto de nosotros (editores que no son bots), la reversión parece un umbral tan bueno como cualquier otro. (2) 'Minor' puede dejar de ser el nombre óptimo para la etiqueta. ¿'Procesal' podría ser más adecuado? No tengo idea de si hay alguna forma de cambiar eso por el bien de los nuevos editores. - jameslucas ▄▄▄ ▄▄▄ ▄▄▄ 03:14, 23 de febrero de 2021 (UTC)
  • Oponerse a las ediciones menores son importantes: los pequeños cambios en el marcado, la ortografía, los espacios en blanco, las mayúsculas, los cambios / actualizaciones de los números, la corrección de errores tipográficos: son las pequeñas cosas que hacen que la máquina más grande funcione. Al eliminar las "ediciones menores" como etiqueta, corre el riesgo de inundar las líneas de tiempo con desorden y potencialmente disuadir a los editores de realizar los cambios menores necesarios en primer lugar. doktorb palabras hechos 07:25, 23 de febrero de 2021 (UTC)
  • Opónganse por Mike Peel. - Jayron 32 19:31, 24 de febrero de 2021 (UTC)
  • Oponerse . Si alguien está marcando de manera inapropiada las ediciones que no son menores como menores, eso es un problema de conducta del usuario, no una razón para desaprobar las ediciones menores. Hablando como alguien que aparentemente ha hecho 318,850 ediciones menores, no tiene ningún beneficio y causa una interrupción obvia si los lectores que no necesitan ser informados cada vez que busco y reemplazo silenciosamente el error ortográfico "objetivo" no pueden filtrarlo de su lista de seguimiento. También haría que revisar los historiales de contribución de los editores (ya sea para procesos como RFA, o simplemente "Estoy buscando la diferencia de esa edición que hiciste la semana pasada") sería más complicado, sin ningún beneficio obvio. -  Iridiscente 19:45, 24 de febrero de 2021 (UTC)
  • Oponerse : personalmente, nunca lo uso, incluso si estoy haciendo ediciones menores ... Realmente es demasiado esfuerzo hacer clic en una casilla cada vez que quiero guardar cambios ... decir que no usarlo no lo es una razón para apoyar y no se ha dado ninguna razón de por qué esto debería desactivarse en primer lugar. - Davey 2010 Talk 23:12, 24 de febrero de 2021 (UTC)
  • Oponerse . Simpatizo un poco con la propuesta, pero el problema y su alcance deben definirse mucho mejor, y la solución propuesta parece ser demasiado radical. Marco las correcciones como menores todo el tiempo; lo mismo para las ediciones delsort manuales. Si la función se usa correctamente, la encuentro bastante útil; Si una edición está marcada como menor en mi lista de seguimiento o en el historial de una página, es mucho más probable que ignore esa edición. Estoy de acuerdo que probablemente haya algún problema con el uso indebido de esta función, pero por el momento no estoy seguro del alcance del problema. Quizás soluciones menos radicales, como limitar la clase de usuarios con derechos de usuario para marcar las ediciones como menores, y tratar de proporcionar una definición más precisa de lo que constituye una edición menor, serían útiles y deberían intentarse primero. Nsk92 ( hablar) 23:50, 24 de febrero de 2021 (UTC)
  • Oponerse a las ediciones menores es útil para distinguir, bueno, qué ediciones son menores. Si las ediciones menores están deshabilitadas, no tenemos forma de distinguir aquí, por lo que perdemos información. La información potencialmente defectuosa, como lo son las ediciones menores marcadas incorrectamente, es peor que la falta de información. Tal vez se limite a autoconfirmado y, en el peor de los casos, se limite a extendido confirmado, pero eliminarlo por completo no es una buena idea. Elliot321 ( discusión | contribuciones ) 01:53, 28 de febrero de 2021 (UTC)
  • Oponerse según lo propuesto por Xaosflux. Estoy abierto a limitar las ediciones menores a autoconfirmedo extendedconfirmed, pero no según lo propuesto. Twassman | Charla | Contribuciones 06:48, 28 de febrero de 2021 (UTC)
  • El soporte hace que la "función de solicitud de modificaciones menores" sea un valor principal del permiso de reversión. Una vez que alguien sepa lo suficiente como para quererlo, debemos dárselo. power ~ enwiki ( π , ν ) 03:03, 2 de marzo de 2021 (UTC)
  • Oponerse a una solución que sería mucho peor que el problema que busca abordar. Las ediciones menores son útiles. Limitarlo a los usuarios confirmados automáticamente podría resolver la mayoría de los abusos (ya que la mayoría de los vándalos no son AC); si hay tal abuso en primer lugar. RandomCanadian ( charla / contribuciones ) 03:44, 2 de marzo de 2021 (UTC)
  • Oponerse . Si bien marcar las ediciones como menores no es muy útil, tiene algunos beneficios cuando se revisa el historial de ediciones de un artículo. Por supuesto, el indicador de "edición menor" es tan confiable como el resumen de la edición (es decir, no mucho) y no debe hacer nada automatizado en función de la presencia o ausencia del indicador. - Kusma ( t · c ) 11:55, 2 de marzo de 2021 (UTC)
  • Soporte . Debería ser un privilegio. En la actualidad, es peor que inútil para el vandalismo y simplemente una sobrecarga cognitiva superflua para los editores de buena fe. Rollo ( charla ) 22:06, 2 de marzo de 2021 (UTC)
  • Limítese a confirmado extendido (la confirmación automática es demasiado fácil de evitar) porque solo los editores experimentados deberían poder marcar las ediciones como menores. Entonces, si ignoro las ediciones menores marcadas, no tendré que preocuparme por perderme ninguna edición que no sea EC. Levivich  acoso / sabueso 04:42, 3 de marzo de 2021 (UTC)
  • Oponerse , no creo que haya un problema que deba resolverse. Creo que las ediciones menores son una herramienta útil para las ediciones menores reales. jort ⁹³ | charla 19:56, 4 de marzo de 2021 (UTC)
  • Oponerse Esta es una solución en busca de un problema. Muchos usuarios, incluido yo mismo, no abusan de las ediciones menores. Esto es como no permitir que nadie coma alimentos porque algunas personas comen demasiado. Gracias, 🐔 ¡  Chicdat   Bawk para mí! 11:58, 6 de marzo de 2021 (UTC)
  • Oponerse a sancionar a quienes abusan de ella. Las ediciones menores son beneficiosas para este proyecto en general. ~ HAL 333 22:16, 7 de marzo de 2021 (UTC)

Discusión (ediciones menores) [ editar ]

Aunque la marca de ediciones menores no es confiable para filtrar todas las ediciones, se puede usar (visualmente) para filtrar las ediciones de los editores que conoce. Esta ventaja, por supuesto, solo está disponible para usted si algunos de sus editores conocidos realmente usan la bandera. isaacl ( charla ) 21:13, 15 de febrero de 2021 (UTC)

@ ProcrastinationReader , ¿su problema real se resolvería cambiando la configuración predeterminada de preferencias para mostrar ediciones menores? Whatamidoing (WMF) ( charla ) 21:55, 15 de febrero de 2021 (UTC)
El problema que tengo es que la funcionalidad no tiene sentido. No creo que nunca tenga sentido ocultar las ediciones menores en una lista de seguimiento. No obstante, el indicador en sí puede ser útil, pero sigue siendo redundante para el resumen + recuento de bytes. Creo que los comentarios de Suffusion of Yellow y The Earwig expresan mis preocupaciones de manera sucinta. Mi segundo problema es que los administradores individuales piensan que es apropiado bloquear incluso un solo editor para su uso del indicador menor (por ejemplo, o bloquear usuarios individuales ). Creo que el problema es bastante frecuente, ya que tiene una sección en una página de políticas ( Wikipedia: Vandalismo # Gaming_the_system ). ProcrastinationReader ( charla ) 22:22, 15 de febrero de 2021 (UTC)
Si pudiera configurar editores específicos para los que se filtrarían las ediciones menores, podría ser más útil. Pero dada la baja cantidad de uso y la cantidad de procesamiento general requerido para ese nivel de filtrado, no creo que valga la pena el desarrollo y el costo de mantenimiento continuo. isaacl ( charla ) 22:40, 15 de febrero de 2021 (UTC)
¿Cómo sabe qué editores filtrar? Creo que sería difícil crear una lista exhaustiva de editores que son incapaces de utilizar la función. Si se trata de una lista local, sería muy difícil para los editores mantenerla (además, si tiene ediciones menores ocultas, ¿cómo sabe qué editores están haciendo un mal uso de la función menor para agregar a la lista ya que, bueno, ganó? ¿Ves sus ediciones?) Si es una lista global, siento más drama ANI sin sentido. Además, pueden ser ediciones únicas que requieren más escrutinio en lugar de una incapacidad continua para determinar qué es menor o qué no lo es. ProcrastinationReader ( charla ) 22:44, 15 de febrero de 2021 (UTC)
Dependerá de los usuarios individuales decidir en quién confían para marcar correctamente las ediciones menores y luego configurar su lista de seguimiento en consecuencia. Pero como dije, no creo que el trabajo para implementar esto justifique el beneficio. No me di cuenta de que la capacidad de filtrado actual permitía configurar el nivel de experiencia; No estoy seguro de si eso es útil o no para la lista de observación. isaacl ( charla ) 00:03, 16 de febrero de 2021 (UTC)
@ ProcrastinationReader , si la función no tiene sentido para usted, ¿por qué propone que ciertos editores sigan usándola?
Creo que si tiene sentido depende de la versión de la lista de seguimiento que estés mirando. Si tiene cada edición mostrada por separado, entonces podría permitirle omitir muchas ediciones que no desea ver (por ejemplo, ClueBot revirtiendo el vandalismo simple , que está marcado como 'menor' pero no como una edición 'bot').
El indicador de edición menor también se muestra en Special: RecentChanges . Esto permite a los editores interesados ​​filtrar (por ejemplo) las ediciones menores de editores con menos experiencia que son la versión más actual de la página . Me imagino que esta sería una lista interesante tanto para los patrulleros contra el vandalismo como para las personas que buscan editores prometedores. Whatamidoing (WMF) ( charla ) 23:05, 15 de febrero de 2021 (UTC)
La respuesta al primer párrafo es su segundo párrafo: para que ClueBot y Hugglers, revirtiendo el vandalismo simple, puedan seguir siendo excluidos de las listas de seguimiento. Es menos restringirlo a ciertos editores y más bien restringirlo para un propósito determinado . Incluso los rollbackers y los administradores no podrían marcar como "cambios gramaticales" menores, por ejemplo, en esta propuesta. ProcrastinationReader ( charla ) 23:21, 15 de febrero de 2021 (UTC)
Ese es el problema con esta propuesta: corregir el vandalismo es solo una de las muchas razones válidas para marcar a un editor como menor, incluidos los cambios gramaticales (escribí una lista no exhaustiva arriba). Parece que estás asumiendo que todo el mundo usa Wikipedia exactamente de la misma manera que tú, lo cual es completamente incorrecto. Thryduulf ( conversación ) 12:28, 16 de febrero de 2021 (UTC)
Como ejemplo, esta edición es claramente una edición menor, pero no tiene nada que ver con el vandalismo. Thryduulf ( conversación ) 12:39, 16 de febrero de 2021 (UTC)
  • Dado que es poco probable que esta propuesta obtenga un consenso tal como está redactada, aquí hay una sugerencia completamente diferente, más dirigida a lo que veo es el problema más atroz: el hecho de que ocasionalmente bloqueamos a editores que de otro modo serían productivos por el mal uso de la función de edición menor. Permita que los administradores deshabiliten la marca de edición menor para un editor como parte de la interfaz de bloqueo, en la misma línea que los bloques parciales o la deshabilitación del correo electrónico, pero sin restringir la capacidad de edición. -  La  Tijereta  ⟨ charla ⟩ 15:21 16 de febrero 2021 (UTC)
    • Dos pensamientos. La primera, ¿es técnicamente posible? Si no es así, creo que es poco probable que llegue a través de phab e incluso si lo hiciera, ejecutamos el problema de que las personas se denuncien entre sí incluso más que ahora a ANI por "infracciones menores de marcado de edición" para un "bloque de edición menor". La segunda, la característica todavía sería inútil en mi opinión, pero supongo que es solo mi idealismo hablando; si los editores no están siendo bloqueados por el sitio, entonces no me importa tanto. ProcrastinationReader ( charla ) 16:40, 16 de febrero de 2021 (UTC)
      Actualmente no es posible, requeriría tiempo de desarrollador. Eso solo lo hace un poco desesperado, supongo. Pero todavía estoy interesado en cómo podemos resolver este problema de una manera más específica. -  La  Tijereta  ⟨ charla ⟩ 16:52 16 de febrero 2021 (UTC)
      De hecho, actualmente no es técnicamente posible, pero recientemente se ha realizado mucho trabajo en bloques parciales y marcar las ediciones como menores es algo que se otorga solo a un subconjunto de usuarios, por lo que me parece que es algo que va a ser posible. con una cantidad razonable de trabajo (aunque no soy desarrollador). Sin embargo, pensar en formas de resolver el problema real de una manera enfocada que no cause un daño colateral masivo es absolutamente lo correcto; de hecho, este es el tipo de cosas que deberían haberse hecho antes de venir aquí con una propuesta. solo un RFC. Thryduulf ( conversación ) 17:25, 16 de febrero de 2021 (UTC)
      @ The Earwig y ProcrastATINGReader : He creado una tarea fantástica para esto, consulte phab: T274911 . Thryduulf ( conversación ) 17:29, 16 de febrero de 2021 (UTC)
      Dado que minoredites un derecho de usuario separado, si un bot lo asignara en lugar de ser un conjunto de permisos para todos los usuarios, entonces podría eliminarse de cualquiera que lo usara de manera inapropiada. isaacl ( charla ) 19:36, 16 de febrero de 2021 (UTC)
      @ Isaacl : ¿Creo que podría estar mezclando algunos términos aquí? Podría ser posible hacer un grupo que incluya el minoredit permiso ; y sería posible hacer que se asigne automáticamente una vez en un umbral (como Extendedconfirmed) de modo que pueda ser revocado, pero eso es una gran sobrecarga para un permiso tan pequeño (y no creo que obtengamos "bots" involucrados en este proceso). - Charla xaosflux 19:50, 16 de febrero de 2021 (UTC)
      No es algo de lo que sepa mucho, así que es casi seguro. Dejé de hablar de grupos por simplicidad, y no sabía (u olvidé) acerca de la asignación automática una vez; mis disculpas. Sí, sería una sobrecarga, pero menos que mejorar la capacidad de bloqueo parcial para permitir que un usuario no marque ediciones menores. isaacl ( charla ) 19:55, 16 de febrero de 2021 (UTC)
      También sería posible, sin gastos generales en el caso común o esfuerzo de codificación, crear un grupo que elimine la capacidad de realizar una edición menor usando $ wgRevokePermissions . Esta forma de hacerlo también evita el problema de que los bloques se vean como una mancha en el registro de las personas que fue señalado por Suffusion of Yellow a continuación. Dicho esto, estoy lejos de estar convencido de que todo esto sea realmente una buena idea. * Pppery * ha comenzado ... 23:38, 16 de febrero de 2021 (UTC)
      @ Pppery : a partir de una verificación rápida, tenemos exactamente un proyecto que usa esa configuración en todo WMF, y parece que no lo han usado en más de 10 años, así que me sorprende que todavía esté disponible (parece que puede fusionarse en t pblocks - ver phab: T227618 ). Por supuesto, deja una "mancha" en el registro de derechos del usuario (por ejemplo, w: ta: Special: Redirect / logid / 58001. - Charla xaosflux 00:11, 17 de febrero de 2021 (UTC)
      Como recuerdo cuando estaba trabajando con otra implementación de Wiki que tenía una funcionalidad similar, puede ser útil en un entorno corporativo al definir grupos de usuarios y administrar sus permisos. isaacl ( charla ) 00:20, 17 de febrero de 2021 (UTC)
    • Esta sería una fantástica fuente de drama. Un bloqueo (incluso un bloqueo parcial) no es solo la incapacidad técnica para hacer algo, sino que (para bien o para mal) el usuario lo verá como una "mancha" en su registro. Por algo tan trivial como esto, no parece que valga la pena. Suffusion of Yellow ( charla ) 20:00, 16 de febrero de 2021 (UTC)
  • Cuando ve una edición de ± 10k marcada como menor, sabe que es casi seguro que el editor no está haciendo nada bueno. Narky Blert ( charla ) 17:55, 16 de febrero de 2021 (UTC)
  • Aparentemente, más de siete mil usuarios han sido advertidos por marcar las ediciones que no son menores como menores. ¿Ha sucedido alguna vez lo contrario ? Es decir, "está haciendo correcciones de errores tipográficos pero no las marca como menores, comience a usar la bandera o lo arrastraré a AN / I". Suffusion of Yellow ( charla ) 19:52, 16 de febrero de 2021 (UTC)
    Cuando entreno, siempre digo que si tiene alguna duda sobre si una edición es menor, asuma que no es lo peor que sucederá si alguien le dará un consejo amistoso, pero marcar una edición importante como menor podría hacer que la gente se enoje. a ti. Thryduulf ( conversación ) 21:06, 16 de febrero de 2021 (UTC)
  • Me sorprende que los editores productivos estén siendo bloqueados por su uso de marcas de edición menor. ¿Hay más casos que el mencionado por The Earwig arriba? Ese caso en particular parece muy inusual ya que el editor aparentemente está usando una aplicación de iOS que no recibe notificaciones y, por lo tanto, no responde a los comentarios. Alguien que está siendo bloqueado por vandalismo marcado como menor claramente está siendo bloqueado por vandalismo. Espresso Addict ( charla ) 00:44, 17 de febrero de 2021 (UTC)
    Buena pregunta, Espresso Addict . Desenterré algunos ejemplos de editores bloqueados por marcar ediciones como menores. En la mayoría de los casos, hay otras razones para los bloqueos, por supuesto: [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14 ] [15] [16] [17] [18] . -  La  Tijereta  ⟨ charla ⟩ 07:37, 17 de Febrero 2021 (UTC)
  • Comentar . Voté en contra e indiqué que estaría dispuesto a limitar quién puede marcar las ediciones como menores. Desde entonces, he notado que varias personas han sugerido que solo se permita a los usuarios confirmados automáticamente marcar las ediciones como menores, pero tenía la impresión de que ya estaba limitado a usuarios confirmados automáticamente. Si no es así, no veo ninguna razón por la que ese no debería ser el caso. - Calidum 21:11, 24 de febrero de 2021 (UTC)
    @ Calidum : La situación actual es que no necesita ser autoconforme para marcar las ediciones como menores, simplemente inicie sesión . - Red rose64 🌹 ( charla ) 17:12, 25 de febrero de 2021 (UTC)
  • Algunos de los temas que vigilo son propensos al vandalismo POV. A menudo, los vándalos intentan ocultar su vandalismo detrás de una etiqueta de "edición menor". Esto es (contraintuitivamente) bastante útil cuando se trata de detectar y limpiar tal vandalismo ... He aprendido a prestar más atención a las ediciones que están marcadas como "menores". Por lo tanto, me opondría a eliminar la etiqueta. Blueboar ( charla ) 23:03, 24 de febrero de 2021 (UTC)

Sellos de fecha de clase [ editar ]

Varios artículos tienen en la página de discusión una etiqueta de calidad en forma de niveles de clase. Sin embargo, es bastante difícil saber cuándo se realizó la evaluación y, a menudo, la evaluación puede tener varios años y no corresponde al nivel actual del artículo. ¿Sería posible agregar una marca de tiempo en estas evaluaciones (de la misma manera que para las plantillas que indiquen la necesidad de edición en el artículo en sí)? Idealmente, esto se haría de forma retroactiva con robots pasando y agregando marcas de tiempo a todas las evaluaciones ya realizadas. - Olle Terenius (UU) ( conversación ) 11:17, 16 de febrero de 2021 (UTC)

¡Hmm, pensamiento interesante! El beneficio tendría que sopesarse con el potencial de desorden en las listas de vigilancia. Creo que la primera reforma que debe ocurrir con las evaluaciones de calidad es unificarlas en una por artículo, en lugar de tener una por proyecto por artículo. {{u | Sdkb }}  charla 03:14, 17 de febrero de 2021 (UTC)
No es que tenga ninguna pista o participación en proyectos de evaluación de artículos, pero tal unificación no sería potencialmente difícil, especialmente. cuando hay más de un par de proyectos involucrados? Quiero decir, considere el artículo (actualmente ficticio) Música militar de Polonia como un caso hipotético. El proyecto polaco está contento con él y lo evalúa muy bien, pero la gente del proyecto Music ve que le falta un montón de la música necesaria, eh, cosas que necesitan. La tripulación militar podría tener una tercera opinión sobre la calidad del artículo. Y nuevamente, no tengo idea de cuán realista es este escenario. -  JohnFromPinckney ( charla ) 03:30, 17 de febrero de 2021 (UTC)
[Editar conflicto] Si bien puedo ver que a algunas personas no les gusta abarrotar las páginas de discusión con múltiples evaluaciones, es común que diferentes proyectos tengan diferentes estándares y que el material de un proyecto esté bien cubierto mientras que falta el de otro. ¿Cómo decidiríamos de quién es la opinión que prevalece? Además, si las evaluaciones estuvieran unificadas, ¿qué pasaría con las evaluaciones de importancia, que claramente difieren entre proyectos? Espresso Addict ( charla ) 03:38, 17 de febrero de 2021 (UTC)
Creo que tiene sentido mantener las evaluaciones múltiples. Como se dijo, los diferentes temas del artículo pueden tener niveles muy diferentes de cobertura y / o calidad y ayudaría a la persona que edita el artículo a saber dónde poner el énfasis. - Olle Terenius (UU) ( conversación ) 11:41, 4 de marzo de 2021 (UTC)
En general estoy de acuerdo con esto, pero algunos proyectos (como el wikiproject militar) hacen su propia evaluación (por ejemplo, calificaciones de clase A). Eso tendría que permitirse que continúe. Pero la mayoría de los proyectos no son realmente tan activos o bien organizados como MILHIST, y la mayoría de las calificaciones ni siquiera las realizan los miembros de WP, sino solo los patrulleros de página, etc. Así que, probablemente, algo debería mejorar en el sistema. ProcrastinationReader ( charla ) 05:26, 18 de febrero de 2021 (UTC)
La evaluación por wikiproyecto está muerta y simplemente debería quedar obsoleta. Ya se sobrescribió formalmente para GA y FA, ​​y no estoy seguro de que alguna vez suceda fuera de MILHIST A-class. Si MILHIST califica un artículo como de clase A, esa calificación debería aplicarse a la calidad del artículo en su conjunto, y podría recibir una única marca de tiempo como lo hacen actualmente GA y FA. CMD ( charla ) 07:21, 23 de febrero de 2021 (UTC)
  • Esto suena como una buena idea, y si los bots pudieran hacerlo, quizás no resulte demasiado difícil. Rollo August ( charla ) 09:18, 20 de febrero de 2021 (UTC)
  • Soporte . Estoy de acuerdo con CMD y algunos de los otros comentarios. Es interesante que haya un proceso formal para GA y FA, ​​pero cuando se trata de las calificaciones B y C, es muy flexible y permitimos que coexistan múltiples calificaciones en la página de discusión, dadas por diferentes WikiProjects, potencialmente. No permitiríamos eso para GA y FA, ​​entonces, ¿por qué para B y C? Además, me gusta la información llamada "hitos" que está disponible para los artículos de la FA, consulte, por ejemplo, "mar" aquí.. Podría ser solo un pequeño cambio técnico que sería útil para indicar cuándo se realizó la última evaluación (si es demasiado difícil hacerlo retrospectivamente, podría hacerse de ahora en adelante). De modo que si llego a un artículo y dice C en la página de discusión, puedo ver inmediatamente cuándo se proporcionó la calificación C y quién lo hizo. Si la calificación tenía 5 años, entonces podría impulsarme a tomar medidas para verificar si es necesario actualizar la calificación. EMsmile ( charla ) 01:28, 4 de marzo de 2021 (UTC)

Páginas de usuario [ editar ]

En mi opinión, sería mejor permitir las ediciones de la página del usuario y sus subpáginas solo al "propietario de la página". Por ejemplo, si el usuario X crea su página, solo él podrá editarla - Dr. Salvus ( hablar ) 15:15, 25 de febrero de 2021 (UTC)

Hay muchas razones por las que los no "propietarios" querrían editar estas páginas. Artículos de usuario. Mover borradores de AfC. Etiquetado para eliminación. Etiquetado de calcetines. Corregir errores de sintaxis. Desactivación de categorías de espacio principal. Eliminación de imágenes de uso legítimo. Eliminar contenido ofensivo. Eliminación de violaciones de derechos de autor. El usuario puede ser una cuenta alternativa. Puede ser una cuenta de bot. Puede albergar una página / lista pública para su edición / mantenimiento. Y luego están los archivos de la página de conversación del usuario. Etc., etc. -  HELL KNOWZ    ▎ TALK 15:21, 25 de febrero de 2021 (UTC) 
Tenga en cuenta que los usuarios no confirmados automáticamente ya tienen prohibido editar páginas de usuario a través de un filtro de edición . No creo que haya ninguna razón por la que las páginas de usuario deban restringirse de tal manera, hay muchas razones (como se articuló anteriormente) para editar páginas en el espacio de usuario de otra persona. - csc -1 20:49, 25 de febrero de 2021 (UTC)
Estaría totalmente en contra del consenso de la comunidad existente en Wikipedia: Propiedad del contenido y Wikipedia: Páginas de usuario # Propiedad y edición de las páginas de usuario . Como se mencionó, ya existe un filtro de edición para evitar el vandalismo por parte de editores no confirmados en páginas de usuario que no son las suyas. ✨ ¡ Habla Ed ! ✨ 21:06, 25 de febrero de 2021 (UTC)
  • A veces, las ediciones en la página de usuario de uno pueden ser útiles. En el caso de recibir estrellas de granero, seguramente debería hacer que uno se sienta afirmado. Rollo August ( charla ) 19:28, 28 de febrero de 2021 (UTC)
El año pasado, he visto esta propuesta tres veces aquí. ¿Por qué no convertirlo en una propuesta de WP: PERENNIAL ? 🐔 ¡  Chicdat   Bawk para mí! 11:54, 1 de marzo de 2021 (UTC)
  • ¿Estamos incluyendo todas las páginas dentro del ESPACIO DE USUARIO de un usuario (la página de usuario principal, su página de discusión asociada ... así como cualquier página de borrador / sandbox y sus páginas de discusión asociadas) o estamos limitando esta discusión a solo la página principal de un usuario? Blueboar ( charla ) 13:34, 1 de marzo de 2021 (UTC)
  • Eso va en contra del espíritu del WP: Five Pillars , así que no creo que sea una buena idea. Dennis Brown - 2 ¢ 11:59, 2 de marzo de 2021 (UTC)
  • Como se dijo anteriormente, hay muchas razones válidas para no bloquear tanto: apoyaría un bloqueo en los editores anónimos / de IP que editan otras páginas de usuario (además de hablar), ya que esta es, con mucho, la más disruptiva y podrían informar copy-vios, abuso, etc. a muchos otros lugares para resolver problemas si es necesario. KylieTastic ( charla ) 16:35, 2 de marzo de 2021 (UTC)
  • De ninguna manera. Si un usuario realiza un cambio no constructivo en su espacio de usuario, es bastante fácil de revertir y puede ser bloqueado por vandalismo. Muchos usuarios hacen cosas como ejecutar encuestas en su espacio de usuario o ensayos a los que no les importa que otros usuarios realicen modificaciones. Posiblemente, limitarlo a los usuarios confirmados automáticamente puede ser razonable; estoy bastante seguro de que los nuevos usuarios no pueden crear nuevas páginas en el espacio de usuario de otras personas. Además, los administradores generalmente están dispuestos a proteger las páginas de los usuarios de lo que he visto. Elliot321 ( discusión | contribuciones ) 20:34, 3 de marzo de 2021 (UTC)

Wikipedia: Lista de wikipedistas por número de ediciones [ editar ]

¡Hola! Propongo extender esta clasificación a los 20.000 mejores wikipedistas por número de ediciones, en lugar de 10.000. Dr. Salvus ( charla ) 14:17, 28 de febrero de 2021 (UTC)

@ Dr. Salvus : He cambiado su "mejor" a "superior" para tratar de evitar descarrilar la discusión. El inglés no es tu lengua materna y supongo que "top" cubre mejor lo que quieres decir. PrimeHunter ( charla ) 14:37, 28 de febrero de 2021 (UTC)
¿Sería posible hacer esto? El problema obvio es que podría alentar a Wikipedia: Editcountitis . Rollo August ( charla ) 19:32, 28 de febrero de 2021 (UTC)
Ciertamente es posible , pero es un informe generado por un bot, entonces, ¿el operador del bot ( MZMcBride ) está dispuesto a hacer el cambio? Si es así, ¿la comunidad lo desea? Coloqué una nota en la charla de Wikipedia: Lista de wikipedistas por número de ediciones . - Red rose64 🌹 ( charla ) 09:58, 1 de marzo de 2021 (UTC)
  • Si bien creo que WP: WBE es algo bueno en general junto con otras métricas que brindan comentarios positivos a los esfuerzos de los editores, me preocupa que abrirlo para un número bajo de ediciones totales tenga muchas más probabilidades de alentar a Wikipedia: Editcountitis . Dado que ya está dividido 1-5000 y 5001-10000 si se aumenta, sugeriría que solo se agregue 10001-15000 no hasta 20000. KylieTastic ( charla ) 10:22, 1 de marzo de 2021 (UTC)
  • Meh, estaré más interesado en Wikipedia: Lista de wikipedistas por número de nominaciones a la FA . disfrutador | charla 10:30, 1 de marzo de 2021 (UTC)
    Disfrutador del mundo , eso existe. Redirigí tu enlace rojo a la página. {{u | Sdkb }}  charla 07:19, 2 de marzo de 2021 (UTC)
    Fresco. disfrutador | charla 08:31, 2 de marzo de 2021 (UTC)
  • Yo apoyo firmemente ~ 12.000, el apoyo de 15.000, débilmente se oponen a 20.000, y se opone fuertemente cualquier cosa más allá de 20.000. 🐔 ¡  Chicdat   Bawk para mí! 11:29, 1 de marzo de 2021 (UTC)
  • ¡Doble Meh! Los recuentos de ediciones no tienen mucho sentido como métrica. ¿Por qué molestarse? G en Q uest "scribble" 02:41, 2 de marzo de 2021 (UTC)
  • Triple meh! Editcountitis es la forma más sucinta de describir esto; y como dice GQ, son una métrica prácticamente sin sentido. RandomCanadian ( charla / contribuciones ) 04:01, 2 de marzo de 2021 (UTC)
  • Oponerse . Estoy de acuerdo con las preocupaciones de editcountitis. Además, más allá de 10,000 (y posiblemente incluso más allá de 5,000), las clasificaciones son tan altas que no es una métrica muy significativa. {{u | Sdkb }}  charla 07:22, 2 de marzo de 2021 (UTC)
  • Yo estaría en contra de eso simplemente porque 10k es más que suficiente. La lista tal como está posiblemente no hace mucho para mejorar la enciclopedia, no estoy seguro de cómo expandirla. Dennis Brown - 2 ¢ 12:01, 2 de marzo de 2021 (UTC)
  • Cuádruple meh , incluso apoyaría acortar la lista. ~ HAL 333 19:22, 4 de marzo de 2021 (UTC)
  • Soporte . Yo digo, si la gente quiere una lista más larga, déjeles hacer una lista más larga. Puede estar en una subpágina. Si subir en la lista anima a algunos editores a realizar ediciones productivas , vale la pena. BD2412 T 19:37, 4 de marzo de 2021 (UTC)
  • Compatible con BD2412. La enumeración de hoy dice: "A partir del lunes 8 de marzo de 2021, 02:13 (UTC), la Wikipedia en inglés tiene 41,101,321 usuarios registrados, 143,161 editores activos y 1,109 administradores. Juntos, hemos realizado 1,006,207,773 ediciones, creado 52,919,998 páginas de todo tipo y creó 6.266.459 artículos ". Haga que la longitud de la lista sea tan extensa como MZMcBride esté dispuesta a darle servicio, incluso hasta 100.000 o incluso todos los activos, si el espacio disponible es ilimitado. Si ver sus nombres en la lista es el aspecto que podría inspirar a algunos editores a una productividad útil, entonces el cielo debería ser el límite. - Roman Spinner (charla • contribuciones) 03:30, 8 de marzo de 2021 (UTC)
  • Aumento de soporte a 20.000. Todo es solo por diversión. Wikipedia: Lista de wikipedistas por número de ediciones # Lector de advertencia y Wikipedia: Recuento de edición # "Calidad, no cantidad" ayudan a explicar por qué los números son solo números y no deben tomarse demasiado en serio. Creo que se pueden crear nuevas subpáginas como Wikipedia: Lista de wikipedistas por número de ediciones / 5001–10000 para los siguientes dos lotes de 5000. Luego, se pueden agregar enlaces a ellos aquí Wikipedia: Lista de wikipedistas por número de ediciones # Lista de wikipedistas por número de ediciones . Aquellos editores que estén interesados ​​en rastrear sus números pueden seguirlos allí y aquellos que no lo encuentren de interés pueden simplemente ignorarlo como ha sucedido hasta ahora. MarnetteD| Charla 04:07, 8 de marzo de 2021 (UTC)
  • En su mayoría inofensivo , estaría más interesado en ver una lista clasificada por contenido agregado. El contenido mejorado también sería una métrica interesante si alguien puede averiguar cómo medirlo. · · · Peter Southwood (charla) : 07:38, 8 de marzo de 2021 (UTC)
  • Soporte por MarnetteD. He estado al final de los 5.000 mejores durante mucho tiempo y, en ocasiones, mantenerme en la lista me ha motivado para editar. Así que presumiblemente otros podrían estar motivados para permanecer entre los 20.000 primeros. Tal vez eso suene inmaduro, pero es más productivo que buscar me gusta, re-tweets o deslizar el dedo hacia la derecha. Adrian  J.  Hunter ( charla • contribuciones ) 07:52, 8 de marzo de 2021 (UTC)
  • Comentario : si las personas que están por debajo del top 10,000 están interesadas en saber cómo se clasifican, creo que sería más útil tener una palabra mágica que devuelva su rango (presumiblemente también querríamos una que devuelva su recuento) que tener esa información recopilada en una página. Las páginas de lista solo son útiles cuando alguien puede querer verlas como un todo, en lugar de simplemente buscar a un usuario específico. Definitivamente es concebible que alguien quiera ver a los 100 mejores como grupo, pero realmente no puedo imaginar que alguien que se ubique en el puesto 14,704 esté interesado en ver a los usuarios por encima de ellos en 14,600 o realmente tener algún uso para los 10k- 14k página en todo lo que no sea encontrarse en ella. {{u | Sdkb }}  charla 01:20, 9 de marzo de 2021 (UTC)
  • Regla 80/20 reglas Wikipedia se puede encontrar en todas partes; resaltar aproximadamente el 20% de los editores más prolíficos sería lógico. - Green C 01:35, 9 de marzo de 2021 (UTC)

Citar la visualización del libro: los colaboradores / contribuciones deben SEGUIR al autor / título, no precederlos [ editar ]

Se trasladó a charla CS1 . Por favor comente más allí. {{u | Sdkb }}  charla 07:16, 2 de marzo de 2021 (UTC)
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.

Aquí estoy editando Carl Marzani # Publicado por Marzani & Munsell . La entrada de preocupación se muestra como

  • King, Jr., Martin Luther; Nelson, Truman (1962). Prefacio. Negros con pistolas . Por Williams, Robert F. Nueva York: Marzani & Munsell. OCLC 340047.

Solo en Wikipedia la cita otorga la máxima facturación al autor del Prólogo. Eso no es bueno, corríjalo, para que la entrada se vea así:

  • Williams, Robert F. (1962). Negros con pistolas . con Prólogo de Martin Luther King, Jr; Truman Nelson. Nueva York: Marzani & Munsell. OCLC 340047.

Aún mejor, dado que el "Prólogo" son en realidad dos ensayos separados de King y uno de Nelson, sería mejor tener como parámetros contribución1, contribución2 y contribución3. Larry Koenigsberg ( charla ) 18:38, 1 de marzo de 2021 (UTC)

Por favor plantee esto en Charla de ayuda: Estilo de cita 1, que es donde se discuten los problemas de la plantilla de cita. Peter coxhead ( charla ) 19:33, 1 de marzo de 2021 (UTC)
Hecho. Planteado en la charla de ayuda: Estilo de cita 1 # Visualización del libro de la cita: los contribuyentes / contribución deben SEGUIR al autor / título, no precederlos . Larry Koenigsberg ( charla ) 21:50, 1 de marzo de 2021 (UTC)
La discusión anterior 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.

RfC: pronombres colocados en la firma para nuevos usuarios [ editar ]

La siguiente discusión es un registro archivado de una solicitud de comentarios . Por favor no lo modifique. No se deben realizar más ediciones en esta discusión. A continuación se presenta un resumen de las conclusiones alcanzadas.
Ningún cambio.

¿Deberíamos agregar pronombres a las firmas de los nuevos usuarios? ¿Deberíamos agregar pronombres a las firmas de usuarios antiguos? ¿En qué formato deberían estar estos pronombres, si se agregan?

Opciones para nuevos usuarios:

R : Agregue nuevos pronombres a la firma automáticamente cuando se registren, eligiendo sus pronombres en la pantalla de registro.
B : Dar a los nuevos usuarios la opción de agregar sus pronombres a su firma cuando se registren
C : No haga nada, no dé a los usuarios la opción de agregar fácilmente sus pronombres a su firma.

Opciones para usuarios ya existentes:

R : Un impulso para alentar a los wikipedistas a agregar sus pronombres a su firma de la manera que elijan.
B : Colocar automáticamente los pronombres archivados al final de la firma.
C : No animar a los usuarios a agregar pronombres a su firma.

Opciones de formato (utilizándolas como ejemplo):

A : (Ellos / Ellos)
B : (ellos / ellos)
C : [ellos / ellos]

theleekycauldron ( talk • contribs ) ( they / them ) 23:35, 1 de marzo de 2021 (UTC)

Meh ... Lo estás pensando demasiado ... los que se preocupan por sus pronombres suelen dejar que los demás sepan sus preferencias. Algunos lo ponen en su página de usuario (por lo que es una buena práctica verificarlo), la mayoría simplemente lo corrige (cortésmente) si usa algo “incorrecto”. Siempre que respetemos los deseos de otros editores cuando se les informa de sus deseos, todos nos llevaremos bien. Blueboar ( charla ) 00:49, 2 de marzo de 2021 (UTC)
Estoy de acuerdo con Blueboar. Pero un problema real (para mí) es que ahora el software me obliga a elegir entre ellos, ella y él, lo cual es realmente irritante. No me importa cómo la gente se refiera a mí, pero me veo obligado a elegir entre un género y "ellos" está desactivado. Ninguna opción, o prefiero no decirlo, debería ser una opción en la configuración de preferencias. Sandy Georgia ( Discusión ) 00:54, 2 de marzo de 2021 (UTC)
  • Solo para facilitar su uso, creo que deberíamos tener una opción en las preferencias que ayude a los editores a agregar pronombres a su firma, pero sospecho que ir más allá. Hay riesgos de identificarse como un hombre no cisgénero (es decir, mujer, hombre no binario o trans) en Internet, y sin avisar a los nuevos editores de esa realidad, debemos evitar alentar a los editores a revelar información personal que puedan algún día. deseo recuperar. Por supuesto, debemos permitirles que tomen esa decisión, e incluso facilitárselo una vez que hayan tomado una decisión, pero no debemos obligar a nadie a revelar información sobre sí mismos que pueda ponerlos en riesgo de acoso. Por esa razón, creo que agregar pronombres a las firmas de nuevos usuarios automáticamente es una mala idea, e incluso tener una opciónal registrarse es algo que debe evitarse. Para los usuarios existentes, no debemos agregar pronombres automáticamente. Personalmente, tengo referencias neutrales de género establecidas en mis opciones, pero estoy de acuerdo con que los editores usen cualquier pronombre para referirse a mí. Agregar pronombres automáticamente a mi firma haría que pareciera que quisiera que los editores usaran "ellos" exclusivamente cuando ese no es necesariamente el caso. También me gusta mi firma tal como está y no quiero que otros se queden con ella a menos que esté rompiendo algo. En cuanto a cómo formatear los pronombres en firmas, evitaría usar corchetes o llaves, ya que se usan para denotar enlaces y plantillas y podrían causar problemas con el software o los bots. No me importa la capitalización. - Wug · a · po · des 01:14,2 de marzo de 2021 (UTC)
  • Más o menos lo que dijo Wugapodes. Yo apoyaría que sea más fácil para aquellos que deseen agregarlos, pero no apoyo que sea obligatorio. Ni siquiera estoy seguro de qué elegiría, ya que mis pronombres varían según la situación. - Khajidha ( conversación ) 01:29, 2 de marzo de 2021 (UTC)
  • No creo que sea una buena idea por dos razones principales:
    1. No todos los usuarios quieren revelar esta información, especialmente aquellos que suelen ser objeto de acoso en línea por su género, e incluir esto en un formulario de registro implica que se requiere la revelación de género , sin importar que se exprese claramente de otra manera; y
    2. La selección de pronombres no es una simple enumeración; Las políticas de pronombres son mucho más complejas que una trinaria de él / ella / ellos. La forma correcta de manejar esto es como un campo de forma libre, pero solo en inglés un pronombre tiene múltiples formas, por lo que tendríamos que proporcionar múltiples campos, lo que lo convierte en una pesadilla de UX
    El razonamiento detrás de esto es de buena fe, pero no creo que se pueda lograr de la forma en que lo desea el OP .-- Jorm ( charla ) 01:45, 2 de marzo de 2021 (UTC)
  • Estoy de acuerdo con Jorm en gran parte aquí. La implementación de esto, si se hace correctamente, sería simplemente otro campo de forma libre para que los usuarios coloquen cosas ... y aquellos que saben cómo encontrarlo y usarlo probablemente sean aquellos que puedan manejar agregarlos a su firma manualmente si realmente los quieren allí. Tampoco quiero entrar en la idea de que las personas deberían "tener" o incluso ser alentadas a mostrar un conjunto de pronombres; hay muchas personas que desean que se les denomine pronombres diferentes según la situación, y la gente no debería ' sientes que necesitan revelar información que para algunas personas es difícil de revelar.Me preocupa especialmente que los editores que no son de género cis (o aquellos que usan otros pronombres) se vean atrapados entre la espada y la pared, usando sus pronombres preferidos y el daño potencial que podría derivarse de eso, o usando pronombres no preferidos. y tener que verlos a menudo. TLDR: Las personas que quieren sus pronombres en su firma ya pueden hacerlo, y no veo ninguna razón por la que no puedan agregarlo manualmente ahora. Estoy indeciso sobre una alternativa para tener una opción en la configuración; si esto se implementó, creo que debe ser opcional, y la visualización de pronombres en firmas debería serEstoy indeciso sobre una alternativa para tener una opción en la configuración; si esto se implementó, creo que debe ser opcional, y la visualización de pronombres en firmas debería serEstoy indeciso sobre una alternativa para tener una opción en la configuración; si esto se implementó, creo que debe ser opcional, y la visualización de pronombres en firmas debería seropt-in , es decir, no deberían aparecer automáticamente. Nuevamente, esto se debe a que si fuera obligatorio o integrado, las personas se verían perjudicadas por eso. Sin mencionar que simplemente podemos hablar entre nosotros : diablos, la gente ni siquiera sabe si soy hombre, mujer, no cisgénero / no binario (no puedo incluir todas las opciones aquí, obviamente), etc. . Varios editores se han referido a mí como ella en función de mi nombre de usuario, y otros se han referido a mí como él según mi nombre de usuario, y algunas personas se han referido a mí como "ellos" como un intento de ser respetuoso de no saber mi preferencia. Si tuviera un sentimiento fuerte, simplemente enviaría una simple respuesta a la persona que diga mis pronombres preferidos y solicite que intente cumplir. Y así debería continuar. -bɜ:ʳkənhɪmez ( Usuario /¡Di hola! ) 01:54, 2 de marzo de 2021 (UTC)
  • Sin cambios por arriba. Como se dijo, debemos evitar que parezca que revelar el género de uno es una expectativa o un imperativo, y luego algunas personas tienen que confundirse con el género o revelar algo sobre sí mismos que quizás no se sientan cómodos revelando. Y realmente, agregarlos a la firma de uno ya es muy fácil si uno lo desea. Las "preferencias" de uno en la parte superior de la página, cuando se hace clic, tienen un campo donde es fácil escribirlas como parte de la firma. Los editores también pueden revelar su género en su página de usuario, como hacen muchos. Crossroads -talk- 06:17 , 2 de marzo de 2021 (UTC)
    También me opongo a cualquier texto en las pautas que mencionen esta práctica. Para que Wikipedia parezca participar en WP: ADVOCACY para esta práctica es extremadamente inapropiado. Y dada la defensa en el mundo real, cualquier declaración al respecto sugiere inherentemente que se haga y, por lo tanto, se une al ejercicio de la presión social. Una vez más, escribirlos en ese cuadro de preferencias es muy fácil y no necesita instrucciones específicas, y las personas ya pueden escribir algo fácilmente en su página de usuario si lo desean. Crossroads -talk- 06:00, 3 de marzo de 2021 (UTC)
  • Sin cambios (C y C) según Wug y otros anteriores. Los editores deben aprender a dejar de usar el valor predeterminado masculino, se debe recordar amablemente a los editores que usan el valor predeterminado masculino que no lo hagan, y los editores que eligen especificar pronombres en su firma ciertamente deben hacerlo. Sin embargo, no creo que llamar la atención sobre los géneros de los editores haciendo que los pronombres sean predeterminados nos ayude a construir una mejor enciclopedia y, de hecho, podría ver que posiblemente empeorara el acoso contra los editores que no son hombres al hacer que se destaquen. Creo que el status quo de usar singular ellos por defecto funciona bien. {{u | Sdkb }}  charla 07:14, 2 de marzo de 2021 (UTC)
  • Sin cambios Esto parece una solución en busca de un problema. Los comentarios anteriores ofrecen un buffet de buenas razones por las que esto es una mala idea, así que no los repetiré. Dennis Brown - 2 ¢ 11:56, 2 de marzo de 2021 (UTC)
  • Sin cambios En Preferencias  → Perfil de usuario He dejado deliberadamente "¿Cómo prefieres que te describan?" establecido en "Editan páginas wiki" (IIRC, la opción de género neutral era "Prefiero no decirlo" hasta aproximadamente 2014/15). En las discusiones, algunas personas usan un pronombre específico de género cuando se refieren a mí y una proporción de esas personas se equivoca: nunca las corrijo . Curiosamente, las personas que me han conocido rara vez usan un pronombre específico de género para mí. Aun así, me parece divertido cuando la gente lanza una moneda y cae del revés. - Red rose64 🌹 ( charla ) 14:12, 2 de marzo de 2021 (UTC)
  • Sin cambios. Me opongo a alentar la adición de wikitexto adicional a cada firma para esto, si alguien quiere hacerlo por sí mismo, entonces lo que sea, pero no deberíamos alentarlo. Me opondría firmemente a cualquier tipo de requisito de que todas las firmas antiguas de wikitexto deben editarse para agregarlas / cambiarlas por algo como esto, o si alguien decide cambiar de "él" a "ellos" y volver en el futuro. En cuanto a la sección de preferencias sobre qué términos prefiere alguien en la interfaz, SandyGeorgiasi bien dice "ellos", "él" o "ella", no debería estar corriendo con demasiada frecuencia (¿alguna?) de ver realmente "ellos" en el software, ¿verdad? Tiendo a usarlos en singular cuando me refiero a otros editores cuando escribo algo sobre ellos (si no especifican una preferencia) solo porque así es como uso el lenguaje natural de otra manera. @ Theleekycauldron : ¿sabe que la opción de un editor para solicitar ciertos descriptores ya es pública y se puede ver en herramientas como ventanas emergentes cuando coloca el cursor sobre el nombre vinculado de un usuario? - Charla xaosflux 16:04, 2 de marzo de 2021 (UTC)
    @ Xaosflux : No lo sé; No sé dónde se utilizan estas preferencias o cómo pueden estar afectando lo que otros ven sobre mí. Me molesta tanto ser un "ellos" como me molestaría que se esperara que revelara el género. Supongo que mi preocupación es cómo esta configuración de preferencias podría eventualmente usarse, si no es ahora. Todo lo que sé es que no puedo no decir en preferencias. Sandy Georgia ( Discusión ) 17:03, 2 de marzo de 2021 (UTC)
    @ SandyGeorgia : Daré seguimiento a tu charla. - Charla xaosflux 17:06, 2 de marzo de 2021 (UTC)
  • Sin cambios (C / C) No deberíamos exigir la adición de pronombres a cada firma por múltiples razones: la técnica / pragmática (es decir, el wikitexto adicional solo servirá para desordenar las páginas de discusión, y cualquier tipo de solución automatizada requieren tiempo de desarrollador que se necesita urgentemente en otros lugares) y lo 'político' (es decir, no deberíamos exigir a nadie que revele nada con lo que no se sienta cómodo). ƒirefly ( t · c ) 16:16, 2 de marzo de 2021 (UTC)
  • Nada obligatorio : Wikipedia en inglés tiene usuarios en muchos países y lugares donde revelar el género no binario de uno los expone a la persecución o al peligro físico real. No podemos obligar a los usuarios a hacer esto. En cuanto a animar a los usuarios que lo deseen, redactar una guía sería un buen primer paso, antes de hablar sobre cómo promocionarla. Esto incluiría: cómo configurar sus pronombres de género en el software, cómo agregar código a su firma para mostrar sus pronombres y cómo encontrar / usar las plantillas (como {{ él o ella }} y {{ ellos }}) que rellenan los pronombres de la configuración de género del software de un usuario. ¿Y qué tal una categoría de usuarios dispuestos a preparar código para usuarios con menos conocimientos técnicos? Estaría dispuesto a ayudar a escribir esa guía. Ardilla de Ivanvector (árboles / nueces ) 16:20, 2 de marzo de 2021 (UTC)
    Para el punto de Jorm sobre los pronombres de forma libre: creo que lo estás pensando demasiado. En general, puede salirse con la suya con tres campos: el sujeto en tercera persona (él / ella / xe / ellos), el objeto en tercera persona (él / ella / xem / ellos) y (realmente opcionalmente) el posesivo en tercera persona (su / ella / xyr / su), al menos en cuanto a hacer las cosas automáticamente; otras formas se pueden derivar manualmente. El pronombre del sitio.is demuestra esto de manera bastante simple (ver, por ejemplo, la entrada del sitio para el singular ellos ). No sé qué tan grande sería este proyecto y los desarrolladores probablemente ya tienen cosas más importantes que hacer, pero creo que este es el enfoque más simple si hay cambios de software sobre la mesa. Ardilla de Ivanvector ( árboles / nueces) 16:37, 2 de marzo de 2021 (UTC)
    Realmente me gusta la idea de orientación sobre cómo hacer esto, y me imagino poniendo algo de texto en WP: SIG con el efecto de
    Algunos editores optan por incluir sus pronombres personales en sus firmas usando una estructura como [[User:Example]] ( [[User talk:Example|talk]] · they/them ) 20:42, 2 March 2021 (UTC).
    Incluso si esta discusión no da como resultado ninguna acción en el lado del software (como parece probable), me gustaría que el más cercano resumiera el sentimiento de la comunidad en torno a esta práctica para que podamos redactar un texto preciso para las páginas de la guía. Por esa razón espero que esto no cierre a SNOW. - Wug · a · po · des 20:42 2 de marzo 2021 (UTC)
  • Ningún cambio no puede ver por qué esto es necesario o útil cuando existen pronombres neutrales que son rápidos y fáciles de usar. También hace que las firmas sean más largas y confusas. Prefiero que los editores sean juzgados por sus ediciones y actitud y evite cualquier sesgo / acusaciones basadas en atributos no contribuyentes. KylieTastic ( charla ) 16:27, 2 de marzo de 2021 (UTC)
  • Sin cambios . Animo y apoyo (personalmente) a cualquier usuario que se sienta cómodo haciéndolo para crear una firma personalizada para agregar sus pronombres. Creo que está perfectamente permitido y todo usuario que lo desee debería sentirse cómodo haciéndolo. No veo ningún beneficio en forzar o alentar a las personas que NO se sienten cómodas haciéndolo a que básicamente lo exijan y / o exijan y / o les animen a hacerlo. No he visto a nadie ser castigado por poner voluntariamente sus pronombres en sus firmas, y si lo fuera, estaría allí para defenderlos en todo momento; sin embargo, no creo que necesitemos imponer estas cosas. - Jayron 32 17:12, 2 de marzo de 2021 (UTC)
  • No tengo ningún deseo de averiguar sobre el contenido de la ropa interior de otros wikipedistas, ni si están contentos con el equipo instalado por el fabricante, ni si lo han modificado, ni qué hacen (o no hacen) con él. También prefiero mantener mi equipo fuera de la conversación. Cabayi ( charla ) 17:31, 2 de marzo de 2021 (UTC)
  • Sin cambios Los usuarios pueden editar su firma para que sea (casi) cualquier cosa; agregar (ellos / ellos), etc. ya es posible - GhostInTheMachine hable conmigo 17:35, 2 de marzo de 2021 (UTC)
  • Sin cambios (después de una discusión sobre mi charla con Xaosflux, quien me ayudó a comprender cómo se utilizan los ajustes de preferencias actuales [19] ). Sandy Georgia ( conversación ) 17:54, 2 de marzo de 2021 (UTC)
    • Para cualquiera que quiera hacer un seguimiento de esa parte, consulte la charla de MediaWiki: Yourgender . - Charla xaosflux a las 18:15, 2 de marzo de 2021 (UTC)
  • Sin cambios Una distracción. Cuanto menos se conozca sobre la identidad íntima de los usuarios, mejor. Un autor que se preocupa tanto por esas cosas probablemente debería estar escribiendo en otra parte. Rollo ( charla ) 22:18, 2 de marzo de 2021 (UTC)
  • Ningún cambio por defecto para agregar pronombres a las firmas colocadas en Wikitext no mejorará Wikipedia. Creo que los editores pueden habilitar una información sobre herramientas (como ventanas emergentes) para ver la información ahora. power ~ enwiki ( π , ν ) 22:23, 2 de marzo de 2021 (UTC)
  • Nada obligatorio . Deberíamos hacer que sea trivialmente fácil para las personas agregar sus pronombres, si así lo desean, y asegurarnos de que las personas sepan cómo hacerlo, si así lo desean, pero no debemos presionar a nadie para que lo haga o no lo haga. Personalmente, lo haría, pero entonces mis pronombres son él / él, que es el único conjunto que tiene menos probabilidades de atraer una atención no deseada. Tengo el privilegio específicamente masculino cis de poder hacer esto sin riesgo. Puedo entender fácilmente por qué otras personas, con otros pronombres, pueden ser mucho más cautelosas. - DanielRigal ( charla ) 22:44, 2 de marzo de 2021 (UTC)
  • Oponerse , tenemos derecho a revelarnos a nosotros mismos, y también tenemos derecho a no hacerlo. Hay mucha infraestructura existente en MW para discernir cómo referirse a un usuario; algunos de nosotros elegimos divulgarlo, pero que me lo impusieran me parecería increíblemente condescendiente. - a ellos / ellos | discutir | contribuciones 07:24, 3 de marzo de 2021 (UTC)
Como persona no binaria, estoy completamente de acuerdo, pero creo que debería ser mucho más accesible agregar pronombres a una firma. theleekycauldron ( talk • contribs ) ( they / them ) 09:19, 3 de marzo de 2021 (UTC)
La discusión anterior 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.

Recuperando la Copa GA [ editar ]

Simplemente propongo traer de vuelta la Copa GA, que se abandonó hace unos años, para reducir la acumulación de nominaciones GA. Puedes leer un poco más sobre mi propuesta aquí . Si desea participar en la Copa GA, hágamelo saber en los comentarios a continuación. X-Editor ( charla ) 06:21, 3 de marzo de 2021 (UTC)

  • Soporte ¿Por qué no? ~ HAL 333 19:21, 4 de marzo de 2021 (UTC)
¡Exactamente! Esto ayudará mucho con la acumulación. Dado que ya ha pasado bastante de este año, tal vez podríamos comenzar la próxima Copa GA a mediados de 2021 y finalizarla a mediados de 2022. El siguiente comenzará a principios de 2023 y terminará a fines de 2023. X-Editor ( charla ) 21:36, 4 de marzo de 2021 (UTC)
  • Soporte: Eso suena útil, la acumulación actual es extremadamente desalentadora. - Astrophobe ( conversación ) 23:11, 4 de marzo de 2021 (UTC)
  • Apoyo Apoyo cualquier cosa que reduzca la acumulación. 🐔 ¡  Chicdat   Bawk para mí! 12:17, 8 de marzo de 2021 (UTC)
  • Para cualquier persona interesada en este tema, existe una recopilación de trabajos pendientes de GA hasta el mes de marzo. Desde el comienzo de la pandemia, han estado realizando una campaña cada pocos meses. Ajpolino ( charla ) 16:12, 8 de marzo de 2021 (UTC)
    Como señala Ajpolino , ha habido una campaña de GA cada seis meses con niveles decentes de éxito. Supongo que no estaría de más volver a probar la copa GA y ciertamente participaría, pero me pregunto si el interés en la revisión podría mantenerse durante más de un mes a la vez.
    Si buscamos soluciones más radicales, lo que siempre diré es mirar el informe y señalar aquellos con muchas nominaciones abiertas. En este momento hay dos usuarios con un total de ochenta nominaciones abiertas que han realizado cuarenta revisiones alguna vez . Ese es posiblemente el factor que más contribuye a la acumulación de trabajos pendientes: las personas que escriben grandes cantidades de contenido pero que no se molestan en revisarlas a cambio. (Por supuesto, la mayoría de los escritores de ga prolíficos se limitan a un número razonable de artículos abiertos a la vez o que revisan sucesivamente ( Sturmvogel 66 y The Rambling Man me vienen a la mente como escritores y críticos prolíficos), pero hay algunos que no lo hacen. es frustrante) Eddie891 Hablar Trabajo 16:29, 8 de marzo de 2021 (UTC)
    Eddie891 , ¿Por qué no usar el sistema quid pro quo como lo hacen en DYK? - RoySmith (charla) 22:34, 8 de marzo de 2021 (UTC)
  • Oponerse hasta que el formato, las consecuencias en otros concursos como WikiCup, la garantía de revisiones de calidad, etc., se aclaren y acuerden. The Rambling Man (¡ Mantente alerta! ¡Controla el virus! ¡Salva vidas! ) 16:43, 8 de marzo de 2021 (UTC)
@ The Rambling Man : No estoy seguro de cuál sería el formato de una nueva GA Cup, pero imagino que sería similar a los formatos de las GA Cups anteriores que se hicieron hace varios años. X-Editor ( charla ) 22:29, 8 de marzo de 2021 (UTC)
Antes de que todos nos dejemos llevar y votemos por esto, es necesario definirlo adecuadamente. The Rambling Man (¡ Mantente alerta! ¡Controla el virus! ¡Salva vidas! ) 22:31, 8 de marzo de 2021 (UTC)
@ The Rambling Man : Estoy de acuerdo, por eso quiero preguntarte qué harías si tuvieras la oportunidad de organizar esta Copa GA. X-Editor ( charla ) 23:28, 8 de marzo de 2021 (UTC)
No tengo ni idea. Nunca antes había participado en él, pero no puedes simplemente votar para resucitar algo sin decir qué es lo que vas a hacer en realidad . The Rambling Man (¡ Mantente alerta! ¡Controla el virus! ¡Salva vidas! ) 07:40, 9 de marzo de 2021 (UTC)

Banner de CentralNotice para WikiGap 2021 Rusia [ editar ]

Estimados colegas, por favor comenten sobre la propuesta de banner de CentralNotice para el concurso de artículos de WikiGap 2021 Rusia . (8 de marzo - 8 de mayo, todas las IP de Rusia, solo WP, 1 impresión de banner por semana). Gracias .-- Dmitry Rozhkov ( charla ) 00:10, 7 de marzo de 2021 (UTC)

Páginas wiki que tienen enlaces a otros sitios web de Wikimedia con el mismo tema [ editar ]

Un ejemplo podría ser https://en.wikipedia.org/wiki/Jaguar tendría un enlace a https://species.wikimedia.org/wiki/Parphorus_jaguar y https://simple.wikipedia.org/wiki/Jaguar . Déjame saber lo que piensas. AidTheWiki ( charla ) 16:06, 7 de marzo de 2021 (UTC)

  • Esto ya está hecho ... vea WP en "Modo de escritorio" y mire la barra lateral. Blueboar ( charla ) 16:22, 7 de marzo de 2021 (UTC)