- Bomba de pueblo
- Política
- Técnico
- Propuestas ( persistentes )
- Laboratorio de ideas
- WMF
- Diverso
Esta página contiene discusiones que se han archivado desde Village Pump (propuestas) . No edite el contenido de esta página. Si desea revivir alguna de estas discusiones, comience un nuevo hilo o use la página de discusión asociada con ese tema.
RfC: poblar descripciones de artículos palabra mágica
- 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.
A finales de marzo - principios de abril de 2017, Wikipedia: Bomba de pueblo (propuestas) / Archivo 138 # Rfc: Eliminar la descripción tomada de Wikidata de la vista móvil de en-WP terminó con la declaración de WMF [1] "hemos decidido cambiar las descripciones de wikidata destaque para enwiki por el momento. "
En septiembre de 2017, se descubrió que debido a malentendidos o falta de comunicación, esta función solo se desactivó para un subconjunto de casos, pero permaneció en enwiki para otras cosas (en algunas aplicaciones, resultados de búsqueda, ...) El efecto de esta descripción es que, por ejemplo, durante 2 horas esta semana, todos los que buscaron Enrique VIII de Inglaterra o lo vieron a través de esas aplicaciones o en "páginas relacionadas" obtuvieron la descripción "obedecer a Hitler" [2] (no tengo idea de cuántas personas vieron esto , este buen artículo se ve unas 13.000 veces al día y está semiprotegido indefinidamente aquí para protegerlo contra tal vandalismo).
La discusión sobre esto comenzó en Wikipedia: Bomba de aldea (política) / Archivo 137 # Las descripciones de Wikidata todavía se usan en enwiki y continuó principalmente en la charla de Wikipedia: Wikidata / 2017 Estado de las cosas (¡puedes encontrar las discusiones en el Archivo 5 hasta el Archivo 12 ! ). Al final, la WMF acordó crear una nueva palabra mágica (nombre por decidir), que se implementará si todo va bien cerca de fines de febrero de 2018, que reemplazará el uso de las descripciones de Wikidata en enwiki en todos los casos.
Ahora debemos decidir dos cosas. Fram ( charla ) 09:58, 8 de diciembre de 2017 (UTC)
¿Cómo poblaremos la palabra mágica con descripciones locales?
- Inicialmente, copie las descripciones de Wikidata por bot
- Con un bot, use una versión simplificada de la primera oración del artículo (el método descrito por el usuario: David Eppstein y el usuario: Alsee en la charla de Wikipedia: Wikidata / 2017 State of Affairs / Archive 5 # descripciones de Wikipedia vs descripciones de Wikidata )
- Con un bot, use la información del cuadro de información (por ejemplo, para las personas una combinación de país + ocupación: "cantante estadounidense", "político nepalí", ...)
- Comience con espacios en blanco y complete manualmente (para todos los artículos, o solo para BLP)
- Comience con espacios en blanco, lo que permite completar manualmente y / o por bot (llenado de bot después de la aprobación exitosa del bot según los procedimientos habituales)
- Otro
Discusión sobre población inicial
- # 5 : permite operaciones de bot para conjuntos de artículos más grandes o más pequeños según los criterios que no tienen que decidirse todos a la vez, y anulaciones manuales en todo momento. - Francis Schonken ( charla ) 10:28, 8 de diciembre de 2017 (UTC)
- # 5 es mi preferencia siguiendo el razonamiento a continuación:
- La opción 1, copiar de Wikidata, llenará Wikipedia con muchas descripciones realmente malas, que permanecerán hasta que alguien las arregle. Mis estimaciones iniciales aproximadas son que hay más descripciones de Wikidata malas / inexistentes que buenas. Me opongo firmemente a esta opción a menos que y hasta que alguien presente datos sólidos que indiquen que será una ganancia neta.
- La opción 2, extraer una descripción útil de la primera oración o párrafo, parece una buena idea a primera vista, pero ¿cómo se hará? ¿Alguien que promueve esta opción tiene una buena idea de cuán efectiva sería, cuánto tiempo tomaría y si en promedio produciría mejores descripciones que la opción 1? Esta opción debe considerarse inadecuada hasta que se proporcione alguna evidencia de que es razonablemente factible y hará más bien que mal.
- La opción 3, copiar desde el cuadro de información, puede funcionar para algunos de los artículos que realmente tienen un cuadro de información con una descripción breve útil, o componentes que se pueden ensamblar en una descripción breve útil. Esto puede funcionar para un subconjunto útil de artículos, pero aún no se sabe cuántos. Supongo que menos de la mitad, por lo que no es una buena opción primaria.
- La opción 4, comenzar con espacios en blanco y completar manualmente, es probablemente lo único que se puede hacer para una gran proporción de artículos, supongo que en el orden de la mitad. Tendrá que hacerse, y probablemente sea el valor predeterminado de facto. Es fácil, rápido y no hará daño. Es totalmente compatible con la opción 5, para la que es el primer paso.
- La opción 5 comienza con la opción 4 y aplica soluciones locales ad hoc que pueden resultar útiles. Cualquier daño está localizado, las descripciones de Wikidata se pueden usar cuando sea apropiado, los extractos de clientes potenciales se pueden usar cuando sea apropiado, los mashups de infoboxes se pueden usar cuando sea apropiado, y la entrada manual de personas que realmente saben de qué se trata el artículo se pueden usar cuando apropiado. Creo que no hay una opción mejor, más sencilla y práctica que esta, y sugiero que los proyectos consideren cómo tratar sus artículos. WPSCUBA ya ha ingresado manualmente descripciones breves listas para usar en más de la mitad de sus artículos, que proporcioné como un experimento. Lleva bastante tiempo, pero se vuelve más fácil con la práctica. Algunos editores pueden encontrar que este es un proyecto divertido, otros no, e inevitablemente habrá conflictos, que sugiero que BRD debe manejar como simples desacuerdos de contenido, para ser discutidos en páginas de discusión y finalizados por consenso. En efecto, la opción 5 es la forma wiki. Es simple y flexible, y es probable que produzca los mejores resultados con la menor cantidad de daño. · · · Peter (Southwood) (charla) : 11:26, 8 de diciembre de 2017 (UTC)
- (Hubo un conflicto de edición aquí y elegí agrupar todos mis comentarios · · · Peter (Southwood) (charla) : 11:26, 8 de diciembre de 2017 (UTC))
- # 5 . Si una descripción de Wikidata es adecuada o no, es muy diferente en muchos grupos de artículos. Debe decidirse (y posiblemente poblar el bot) por grupo, a veces por grupo pequeño, y para eso debemos comenzar con descripciones en blanco .-- Ymblanter ( charla ) 11:23, 8 de diciembre de 2017 (UTC)
- Comience por no usarlo en ningún lugar, solo utilícelo como anulación por situación. - Th e DJ ( hablar • contribuciones ) 12:09 8 de diciembre de 2017 (UTC)
- TheDJ , Para aclarar, ¿es esta una Opción 6: Otra que estás proponiendo aquí? es decir, solo agregue la palabra mágica a los artículos donde la descripción corta de Wikidata no sea adecuada, y use la descripción de Wikidata como predeterminada en todos los casos hasta que alguien encuentre un problema y agregue una palabra mágica, después de lo cual la descripción breve se tomará de la palabra mágica. Si este es el caso, ¿cuál es su opinión sobre volver a la descripción de Wikidata por cualquier motivo en una fecha posterior? · · · Peter (Southwood) (charla) : 14:53, 8 de diciembre de 2017 (UTC)
- @ Pbsouthwood : Correcto. No tengo ninguna opinión sobre revertir en un momento posterior. - Th e DJ ( hablar • contribuciones ) 13:42, 11 de Diciembre 2017 (UTC)
- TheDJ , Para aclarar, ¿es esta una Opción 6: Otra que estás proponiendo aquí? es decir, solo agregue la palabra mágica a los artículos donde la descripción corta de Wikidata no sea adecuada, y use la descripción de Wikidata como predeterminada en todos los casos hasta que alguien encuentre un problema y agregue una palabra mágica, después de lo cual la descripción breve se tomará de la palabra mágica. Si este es el caso, ¿cuál es su opinión sobre volver a la descripción de Wikidata por cualquier motivo en una fecha posterior? · · · Peter (Southwood) (charla) : 14:53, 8 de diciembre de 2017 (UTC)
- # 5 . Eso no trata todos los problemas, pero se acerca más a mis puntos de vista, dadas las opciones. Véanse también mis comentarios en WT: Wikidata / 2017 Estado de las cosas / Archivo 12 y
WT: Wikidata / 2017 El estado de las cosasahora archivado en WT: Wikidata / 2017 Estado de las cosas / Archivo 13 . - Dank ( pulsar para hablar ) 14:06, 8 de diciembre de 2017 (UTC)- Peter me pidió una aclaración. Si las personas tienen preguntas específicas o si quieren un resumen de mis publicaciones anteriores, haré todo lo posible por responder. - Dank ( pulsar para hablar ) 15:30, 8 de diciembre de 2017 (UTC)
- Para quien cierre esto: la discusión que comenzó aquí parece continuar en un nuevo RfC en Uso de enlaces de Wikidata . - Dank ( pulsar para hablar ) 15:18, 16 de enero de 2018 (UTC)
- # 5, pero no espere demasiado para completarlo cuando sea posible. Fram ( charla ) 14:14, 8 de diciembre de 2017 (UTC)
- Fram ¿Está recomendando una campaña masiva a corto plazo para producir descripciones breves para que el sistema sea útil? · · · Peter (Southwood) (charla) : 15:09, 8 de diciembre de 2017 (UTC)
- Sí, aunque en mi opinión esto no es necesario para continuar con esto, solo es preferible. Ninguna descripción es mejor que las situaciones actuales, pero las descripciones decentes basadas en enwiki son en muchos casos mejores que ninguna descripción. No es necesario tirar al bebé (las descripciones se mostrarán en la búsqueda, etc.) con el agua del baño. Fram ( charla ) 15:21, 8 de diciembre de 2017 (UTC)
- # 6 - no lo uses. En primer lugar, no ha habido consenso para tener esta palabra mágica; esa es la pregunta que debería haberse formulado en este RfC (ver discusión aquí ). Personalmente, creo que es una mala idea y una pérdida de tiempo para los desarrolladores. Es mejor concentrarse en mejorar las descripciones en Wikidata. Mike Peel ( charla ) 15:27, 8 de diciembre de 2017 (UTC)
- # 6 - Encuentre una solución que monitoree y actualice las descripciones de Wikidata - Si una descripción es lo suficientemente buena para Wikipedia (ns), debería estar en Wikidata. Si el vandalismo está bloqueado en Wikipedia, debería revertirse simultáneamente en Wikidata. Wikidata es el centro de enlaces interwiki y un sitio de almacenamiento para descripciones y datos estructurados que luego son recolectados por motores de búsqueda externos basados en el conocimiento (piense en Siri, Alexa y el Gráfico de conocimiento de Google). Para propósitos de interwiki, deberíamos querer asegurarnos de que las descripciones breves en Wikidata sean precisas, facilitando las Wikipedias en otros idiomas cuando se interconectan con en.wiki. Para la recolección externa, debemos querer evitar que se propague el vandalismo. Los problemas relacionados con el vandalismo y el abastecimiento en Wikidata son reales, pero la solución es que los wikipedistas y nuestros bots anti-vandalismo puedan monitorear y editar fácilmente el material relevante de Wikidata. Las posibles soluciones incluirían: (a) Implementar una funcionalidad similar a cambios pendientes para cambios en descripciones en páginas de alto tráfico o contenciosas; (b) Realizar cambios en descripciones breves que sean visibles de forma destacada en las listas de seguimiento de Wikipedia, dentro del VisualEditor y como una opción de preferencia para los editores de Wikipedia; (c) Desarrollar e implementar la edición en Wikipedia de descripciones breves de Wikidata utilizando algún tipo de herramienta para hacer clic en este lápiz .-- Carwil ( charla ) 15:46, 8 de diciembre de 2017 (UTC)
- Una vez implementadas esas soluciones, puede solicitar un rfC para anular el consenso del RfC anterior que decidió no tener estas descripciones. Este RfC es una discusión para obtener soluciones que le brinden lo que desea en enwiki (descripciones en VE, móvil, ...) sin interferir en lo que hace Wikidata (son libres de tener sus propias descripciones o importar las nuestras). Fram ( charla ) 16:01, 8 de diciembre de 2017 (UTC)
- Carwil , ¿cómo propone que Wikipedia controle el acceso de los vándalos a Wikidata? ¿Está sugiriendo que los administradores de Wikipedia deberían poder proteger los elementos de Wikidata y bloquear a los usuarios de Wikidata?
- Las opciones fáciles son ... la funcionalidad "deshacer" para las descripciones de Wikidata en las listas de seguimiento de Wikipedia, y la opción (a) que propuse anteriormente, algo así como cambios pendientes que protege las páginas de Wikipedia de cambios no revisados de Wikidata. Transferir bots anti-vandalismo de Wikipedia a Wikidata también sería útil .-- Carwil ( charla ) 16:47, 8 de diciembre de 2017 (UTC)
- Cluebot ya se ejecuta en Wikidata. ChristianKl ( charla ) 15:19, 17 de diciembre de 2017 (UTC)
- Las opciones fáciles son ... la funcionalidad "deshacer" para las descripciones de Wikidata en las listas de seguimiento de Wikipedia, y la opción (a) que propuse anteriormente, algo así como cambios pendientes que protege las páginas de Wikipedia de cambios no revisados de Wikidata. Transferir bots anti-vandalismo de Wikipedia a Wikidata también sería útil .-- Carwil ( charla ) 16:47, 8 de diciembre de 2017 (UTC)
- Nos oponemos firmemente a 4 y nos oponemos fuertemente a 5 —Rechacemos cualquier solución que deje en blanco en masa descripciones breves: son una parte funcional de la navegación móvil y del VisualEditor. Como editor y profesor que lleva a los estudiantes a editar Wikipedia, esta última funcionalidad es un ahorro de tiempo crucial. Los dispositivos móviles acceden cada vez más a Wikipedia y las descripciones breves impiden hacer clic en una página solo para descubrir que no es la que está buscando .-- Carwil ( charla ) 15:46, 8 de diciembre de 2017 (UTC)
- Tenga en cuenta que este es un voto doble, Carwil ya expresó un "apoyo" en negrita arriba ... Fram ( charla ) 10:11, 8 de enero de 2018 (UTC)
- ¿Ha analizado la utilidad general de las descripciones de Wikidata y ha descubierto que hay más descripciones buenas que malas, o ha encontrado una manera de encontrar todas las malas para poder cambiarlas a buenas? Si es así, señale sus métodos y resultados, ya que serían extremadamente valiosos. ¿Qué métodos ha utilizado para indicar el daño comparativo causado por las malas descripciones versus el bien hecho por las buenas descripciones? · · · Peter (Southwood) (charla) : 16:14, 8 de diciembre de 2017 (UTC)
- Sí, he analizado una muestra aquí . Encontré que 13 de 30 tenían descripciones adecuadas (aunque 7 de ellas podrían mejorarse), 13 no tenían ninguna descripción, 1 se describió incorrectamente (no era vandalismo), 2 eran redundantes con el título del artículo (es decir, deberían anularse con un espacio en blanco), y 1 representó un caso en el que el artículo de Wikipedia y la entidad Wikidata no eran idénticos y no deberían compartir la misma descripción. Las descripciones redundantes no causarían ningún daño. Etiquetar incorrectamente "Divisiones administrativas de Bolivia" con el subtítulo "entidad territorial administrativa de Bolivia" causaría una leve confusión. La legibilidad proporcionada por las descripciones supera fácilmente los daños. (El único daño convincente se debe al vandalismo, que debe abordarse mejorando las herramientas de vandalismo sin bifurcar las descripciones entre los proyectos). - Carwil ( charla ) 16:47, 8 de diciembre de 2017 (UTC)
- Las opciones 4 y 5 son no dejar nada en blanco, sino poner descripciones breves, que son contenido de texto , en el artículo que describen, donde puedan ser adecuadamente (o al menos mejor) mantenidas por personas que realmente pueden saber de qué trata el artículo. Wikidata puede usarlos si sus términos de uso lo permiten, y si son realmente mejores para los propósitos de Wikidata, lo cual no está claro en la actualidad. · · · Peter (Southwood) (charla) : 16:14, 8 de diciembre de 2017 (UTC)
- Las opciones 4 y 5 implican comenzar con espacios en blanco en todas partes. Toda la propuesta asume que deberíamos bifurcar un conjunto de datos que describa los artículos de Wikipedia en dos versiones editables de forma independiente. La bifurcación de un conjunto de datos siempre crea inconsistencias y reduce la visibilidad de los problemas al dividir la cantidad de ojos para observar los problemas. Es mejor hacer que los ojos de los wikipedistas sean más poderosos y detectar problemas (que son inusuales) que levantar un muro entre los dos proyectos. Mi muestra sugiere que el 90% del tiempo, o más, los dos proyectos están trabajando hacia el mismo objetivo aquí .-- Carwil ( charla ) 16:47, 8 de diciembre de 2017 (UTC)
- Lo hacen, pero es poco probable que WMF cambie hasta que los resultados de Wikipedia no sean peores que los resultados de Wikidata, aunque no tengo idea de cómo medirían eso, ya que no parecen tener mucha idea de la calidad que tendrán. comparando, o si lo hacen, no están interesados en compartirlo.
- El conjunto de datos no se ajusta a Wikipedia. No deberíamos vernos obligados a usarlo. Un conjunto de datos que se adapte a Wikipedia puede no adaptarse a Wikidata. ¿Deberíamos obligarlos a hacerlo? Dos conjuntos de datos significan que Wikipedia puede cuidar el suyo, y Wikidata puede usar lo que encuentre útil de él, y los wikipedistas no están obligados a editar un proyecto en el que no se inscribieron. Usar datos de calidad de mierda en Wikipedia para presionar a los wikipedistas para que editen Wikidata puede tener una reacción negativa que dañará uno o ambos proyectos, no un riesgo que estaría dispuesto a asumir, si pudiera afectar mi empleo, a menos que, por supuesto, me pagaran. para dañar el WMF, pero eso sería teoría de la conspiración, y francamente creo que es poco probable.
- También hice una pequeña encuesta, mis resultados no concuerdan con los suyos, y también son de una muestra tan pequeña que no es estadísticamente confiable. También escribí descripciones breves para unos 600 artículos en WPSCUBA, pero no mantuve registros. La mayoría (más de la mitad) de los artículos necesitaban una nueva descripción, ya que la de Wikidata no existía o era inapropiada. Había algunos que eran perfectamente adecuados, pero menos de la mitad de los que realmente existían, de memoria. Sería posible volver atrás y contar, pero creo que sería un mejor uso de mi tiempo para hacer otros nuevos, si alguien está dispuesto a unirse a un proyecto de este tipo. Tal vez Wikiproject Medicine, o Biography, donde la calidad en realidad puede tener consecuencias en la vida real, pero generalmente no trabajo mucho en esos campos y dudo en pasar a ellos sin alguna participación en el proyecto. Ya me he encontrado con reacciones hostiles ocasionales donde los proyectos se superponen, pero afortunadamente muy pocos. · · · Peter (Southwood) (charla) : 18:18, 8 de diciembre de 2017 (UTC)
- Las opciones 4 y 5 implican comenzar con espacios en blanco en todas partes. Toda la propuesta asume que deberíamos bifurcar un conjunto de datos que describa los artículos de Wikipedia en dos versiones editables de forma independiente. La bifurcación de un conjunto de datos siempre crea inconsistencias y reduce la visibilidad de los problemas al dividir la cantidad de ojos para observar los problemas. Es mejor hacer que los ojos de los wikipedistas sean más poderosos y detectar problemas (que son inusuales) que levantar un muro entre los dos proyectos. Mi muestra sugiere que el 90% del tiempo, o más, los dos proyectos están trabajando hacia el mismo objetivo aquí .-- Carwil ( charla ) 16:47, 8 de diciembre de 2017 (UTC)
- Las opciones 4 y 5 son no dejar nada en blanco, sino poner descripciones breves, que son contenido de texto , en el artículo que describen, donde puedan ser adecuadamente (o al menos mejor) mantenidas por personas que realmente pueden saber de qué trata el artículo. Wikidata puede usarlos si sus términos de uso lo permiten, y si son realmente mejores para los propósitos de Wikidata, lo cual no está claro en la actualidad. · · · Peter (Southwood) (charla) : 16:14, 8 de diciembre de 2017 (UTC)
- @ Pbsouthwood : No creo que haya mucha luz entre el propósito de Wikipedia para estas descripciones (que aún no se ha escrito), el valor de ellas para la aplicación móvil, el valor de ellas para VisualEditor (como desambigadores para hacer enlaces) y el valor de Wikidata como se analiza aquí . Allí, los requisitos incluyen: "una frase corta diseñada para eliminar la ambigüedad de elementos con etiquetas iguales o similares"; evitar puntos de vista, prejuicios, promociones y reclamos controvertidos; y evitar "información que pueda cambiar". Solo el último parece diferir de la descripción ideal de Wikipedia y solo marginalmente: por ejemplo, "actual presidente de los Estados Unidos" tendría que ser reemplazado por "45º presidente de los Estados Unidos". - Carwil ( charla ) 22: 11 y 12 de diciembre de 2017 (UTC)
- Ha habido extensas discusiones entre la comunidad y WMF sobre el tema de la descripción. Ojalá este RFC hubiera pasado por una etapa de borrador antes de su publicación. Es posible que haya otras opciones o problemas que deban resolverse, lo que podría afectar el resultado aquí. Podría ser necesario un RFC de seguimiento.
El consenso anterior de RFC [3] era claramente eliminar las descripciones de wikidata, y esa es definitivamente mi posición. Una opción alternativa sería omitir la creación de una descripción-palabra clave y simplemente tomar la descripción de la oración principal. Eso tiene los beneficios de (1) garantizar que todos los artículos tengan descripciones automáticamente (2) evitar cualquier trabajo de creación y mantenimiento de descripciones y (3) evitaría la creación de una nueva edición independiente e independiente de descripción-vandalismo. La desventaja es que la oración principal no siempre es una excelente descripción breve.
Si optamos por una nueva palabra clave descriptiva, el n. ° 5, n. ° 2 y n. ° 1 son razonables. (El n. ° 3 y el n. ° 4 son básicamente redundantes para la aprobación del bot en el n. ° 5). Sin embargo, como señalo en la siguiente pregunta, el n. ° 5 se puede implementar con un valor predeterminado de wikidata temporal . Esto nos da tiempo para comenzar a completar las descripciones locales antes de que se apaguen las descripciones de wikidata. Esto evitaría que se borren las descripciones de forma abrupta. Alsee ( charla ) 21:49, 8 de diciembre de 2017 (UTC) - # 2 , con # 5 como segunda preferencia. Las descripciones generadas automáticamente parecen ser lo suficientemente buenas para la mayoría de los propósitos. Sandstein 16:14, 10 de diciembre de 2017 (UTC)
- Sandstein , ¿Qué tamaño tenía su muestra de prueba y cómo se eligieron los ejemplos? · · · Peter (Southwood) (charla) : 16:36, 10 de diciembre de 2017 (UTC)
- 5 . La importación masiva de contenido de WD frustra el propósito de deshacerse de las descripciones de WD. James ( charla / contribuciones ) 16:30, 11 de diciembre de 2017 (UTC)
- Solo es cierto por un período limitado hasta que alguien pueda cambiarlos cuando sea necesario. Si el problema es lo suficientemente grande, habrá bots para hacer arreglos, por lo que a mediano plazo no hace mucha diferencia, ya que una vez que las descripciones estén en Wikipedia podemos solucionarlos tan rápido como podamos hacer los arreglos para hacerlo y lo haremos. ya no será impedido por las ofuscaciones de WP: ICANTHEARTHAT de WMF. La parte importante es llevarlos donde tengamos el control para que podamos comenzar a trabajar para hacerlos bien. · · · Peter (Southwood) (charla) : 07:47, 13 de diciembre de 2017 (UTC)
- 5 Básicamente lo que dijo Peter. En algunas áreas, las descripciones de wikidata serán buenas. En otros, la eliminación de la primera oración será buena. En algunos se pueden utilizar datos de infoboxes. Etcétera. Galobtter ( pingó mió ) 16:20, 19 de diciembre de 2017 (UTC)
- 5 - Después de leer las discusiones sobre esto, estoy absolutamente asombrado de que haya ocurrido tanto vandalismo. De todos modos, de vuelta al punto, Wikidata es más que inútil cuando se trata de lidiar con el vandalismo y, como tal, ¡5 es la mejor manera de lidiar con él! . - Feliz Navidad / Feliz Año Nuevo de Davey 2010 23:24, 27 de diciembre de 2017 (UTC)
- Combinación de 1 y 5 . Importante, pero manténgalo oculto hasta que se revise en WP. Doc James ( charla · contribuciones · correo electrónico ) 06:19, 30 de diciembre de 2017 (UTC)
- # 6 Conserve las descripciones de Wikidata y omita solo las que no sean necesarias. Eventualmente, todas las Wikipedias tendrán que usar Wikidata. Moverse hacia adelante y hacia atrás no tiene mucho sentido. Lo único que podríamos hacer es posiblemente agregar funciones para actualizar Wikidata directamente y retener la funcionalidad para omitir la palabra mágica localmente. - Magioladitis ( charla ) 15:56, 30 de diciembre de 2017 (UTC)
- Razonamiento circular. "Usa Wikidata porque tendremos que usar Wikidata"? Fram ( charla ) 10:11, 8 de enero de 2018 (UTC)
- 5 - Por los motivos indicados anteriormente por otros. Tony Tan · charla 04:17, 17 de enero de 2018 (UTC)
- 5 - Por arriba. (Edite solo para aclarar, en el momento en que edité esta subsección, Fish no había cerrado la discusión, ya que cerraron todo el hilo, no hubo conflicto y mi voto no afecta el resultado de todos modos) Solo en la muerte termina el deber ( hablar ) 13:02, 6 de febrero de 2018 (UTC)
Que hacer con los espacios en blanco
¿Qué debemos hacer cuando no hay una palabra mágica, o la palabra mágica no tiene valor?
- Muestra la descripción de Wikidata en su lugar
- No mostrar descripción
- No mostrar descripción para una lista predefinida de casos (listas, páginas de desambiguación, ...) y la de Wikidata de lo contrario (esta es la solución recomendada por el Usuario: DannyH (WMF) en este momento)
- Otro
- Una transición del # 1 al # 2. En la etapa inicial, cualquier artículo que carezca de una descripción local continuará dibujando una descripción de Wikidata. Implementamos la nueva palabra clave de descripción y comenzamos a completar descripciones locales que anulan las descripciones de Wikidata. Una vez que hemos construido una base suficiente de descripciones locales, finalizamos la transición desactivando completamente las descripciones de Wikidata. (Nota:. Alta 16:34, 6 de enero 2018 (UTC) participantes de la discusión anteriores han sido sondeado para discutir esta nueva opción en el apartado de llenado de espacios en blanco: la opción # 5 . )
Discusión sobre espacios en blanco
- # 2 - se acerca más a no tener una descripción por RfC inicial abortado; aquellos que los deseen pueden escribirlos o completarlos automáticamente (según los procedimientos habituales de aprobación de bots). - Francis Schonken ( charla ) 10:28, 8 de diciembre de 2017 (UTC)
- No se ha propuesto ninguna variante / alternativa / compromiso razonable desde que apoyé el número 2 hace un mes. Reemplace a DannyH como intermediario (no es la primera vez que sugiero esto): han sido bastante claros sobre su incapacidad para proponer algo tangible. El bienestar del proyecto de Wikipedia no debe dejarse en manos de aquellos a los que se les paga para mejorar el proyecto pero que no pueden entregar casi nada. - Francis Schonken ( charla ) 10:37, 8 de enero de 2018 (UTC)
- # 5 como un compromiso razonable según varias discusiones a continuación. · · · Peter (Southwood) (charla) : 18:24, 6 de enero de 2018 (UTC)
# 2 La descripción de Wikidata no debe permitirse por defecto cuando no haya un propósito útil que sirva para una descripción breve. Un parámetro vacío de la palabra mágica debe respetarse como una decisión editorial de Wikipedia que no desea una descripción breve. Esta decisión siempre se puede discutir en la página de discusión. Bajo ninguna circunstancia WMF debe forzar una breve descripción no deseada de Wikidata por defecto. Nada impide que alguien agregue manualmente una descripción que también es utilizada por Wikidata, pero esa es una decisión personal del editor y asume la responsabilidad personal como con cualquier otra edición. No proporcionar automáticamente una descripción para una lista predefinida de clases tiene problemas, ya que es posible que esas clases no se definan tan fácilmente como a algunas personas les gustaría pensar. Por ejemplo, la mayoría de los artículos de listas no necesitan una descripción breve, pero algunos sí. Lo mismo puede ser cierto para las páginas de desambiguación. Dejarlos en blanco como primera etapa y no mostrar una descripción breve hasta que un editor (con suerte, competente) haya agregado uno es fácil de administrar para los casos extremos y puede administrarse mediante otros métodos según la opción 5 de población. Es flexible y puede hacer frente a todas las posibilidades. No hay necesidad de hacerlo más complicado y susceptible de romperse en algún momento. Idealmente, la palabra mágica podría recibir un comentario en lugar de un parámetro en el que sería útil una explicación de por qué no debería haber una descripción breve. En este caso, el comentario no debe mostrarse y está ahí para informar a los editores que podrían preguntarse si se ha perdido. · · · Peter (Southwood) (charla) : 11:43, 8 de diciembre de 2017 (UTC) - # 1 - Muestra la descripción de wikidata en su lugar. - Th e DJ ( hablar • contribuciones ) 12:10 8 de diciembre de 2017 (UTC)
- # 2 . Ninguna palabra mágica (y palabra mágica sin parámetro) debería resultar en ninguna descripción, no se mostrarán confusamente a los lectores algunos datos que no son enwiki (mientras que la mayoría de los patrulleros de vandalismo aparentemente los pasan por alto). Hoy, durante 8 horas, tuvimos esta flagrante violación de BLP en una página con 10,000 páginas vistas por día . Usar estas descripciones por defecto (o en absoluto) es una mala idea y fue rechazada en el RfC anterior. Fram ( charla ) 14:21, 8 de diciembre de 2017 (UTC)
- # 1 - De la WMF: proponemos usar Wikidata como alternativa predeterminada si no hay una palabra mágica definida en Wikipedia, porque las descripciones breves son útiles para los lectores (en la aplicación en los resultados de búsqueda, en el módulo de lectura superior, en la parte superior de las páginas del artículo) y para los editores (en el cuadro de diálogo del vínculo Editor visual). Por ejemplo: en el módulo de lectura superior de septiembre que se muestra aquí, 3 de los 5 artículos principales se benefician de tener una breve descripción: no sé quiénes son Gennady Golovkin y Canelo Álvarez , y que se los describa como "boxeador kazajo" y "Boxeador mexicano" me dice si me interesará hacer clic en ellos. (La respuesta es no, no soy realmente un boxeador.) ¡Lo sé, madre! es una película de 2017, pero estoy seguro de que hay muchas personas a las que el título del artículo le parecería completamente desconcertante sin la descripción. Al hacer clic en la lista completa de los artículos más leídos, hay muchos nombres que la gente no sabría: Amber Tamblyn , Arjan Singh , Goran Dragić . Esta es una característica muy popular en las aplicaciones, y sería casi inútil sin las descripciones.
- Queremos crear la palabra mágica, para que los editores de Wikipedia tengan control editorial sobre las descripciones, lo que deberían. Pero si la palabra mágica se deja en blanco en Wikipedia, especialmente en los casos en los que los editores de Wikipedia aún no han escrito una descripción, entonces para la gran mayoría de los casos, mostrar la descripción de Wikidata es mejor que no mostrar nada en absoluto. Como lector que mira ese módulo de lectura superior, quiero saber quién es Gennady Golovkin, y el módulo debería decir "boxeador kazajo", ya sea que el texto provenga de Wikipedia o Wikidata.
- Sé que una gran razón por la que a la gente le preocupa mostrar las descripciones de Wikidata es que la comunidad de Wikidata a veces puede ser más lenta que la comunidad de Wikipedia para detectar ejemplos específicos de vandalismo. El ejemplo que Fram cita de Enrique VIII de Inglaterra mostrando "obedecer a Hitler" durante dos horas es decepcionante y frustrante. Sin embargo, creo que la mejor solución debería ser mejorar la capacidad de la comunidad para monitorear las descripciones breves, de modo que el vandalismo o los errores puedan detectarse y revertirse más rápidamente. El equipo de Wikidata ha estado trabajando para proporcionar una visualización más granular en las listas de seguimiento de Wikipedia, de modo que los editores de Wikipedia puedan ver las ediciones de las descripciones de los artículos que están viendo, sin quedar enterrados por otras ediciones irrelevantes realizadas en ese elemento de Wikidata. Ese trabajo se está rastreando en este ticket de Phabricator, phab: T90436 , pero no estoy seguro de cuál es el estado actual. Ping para el usuario: Lydia Pintscher (WMDE) : ¿sabe cómo está progresando?
- Perdón por volver a esto ahora. Se deslizó a través. Así que hemos seguido trabajando para mejorar los cambios que aparecen en los cambios recientes y la lista de seguimiento aquí de Wikidata. Específicamente, hemos trabajado mucho para escalar el sistema actual, que es un requisito para cualquier mejora adicional. Hemos hecho los cambios que estamos enviando más pequeños y lo hemos hecho para que se envíen menos cambios desde Wikidata a Wikipedia. También hemos implementado un seguimiento de uso detallado en más wikis (cawiki, cewiki, kowiki, trwiki) para ver cómo se escala. Con el seguimiento de uso detallado, ya no verá cambios en los cambios recientes ni en la lista de seguimiento que en realidad no afecten a un artículo como está sucediendo ahora. Los lanzamientos de estos wikis hasta ahora parecen prometedores. En enero, continuaremos extendiéndolo a más wikis y veremos si se escala lo suficiente para enwiki. Al mismo tiempo, hablaremos con varios equipos en la cumbre de desarrolladores en enero para intercambiar ideas sobre otras formas de mejorar la escala del sistema o revisarlo. - Lydia Pintscher (WMDE) ( charla ) 09:31, 19 de diciembre de 2017 (UTC)
- Hemos hablado en las discusiones anteriores sobre los tipos de páginas en las que las descripciones de Wikidata no son útiles para mostrar el artículo, porque describen la página en sí, en lugar del tema del artículo. Los ejemplos que conozco ahora son páginas de categorías (actualmente "página de categorías de Wikimedia"), páginas de desambiguación ("página de desambiguación de Wikimedia"), páginas de lista y la página principal. Esos pueden ser útiles en el caso del cuadro de diálogo de enlace VE, especialmente "página de desambiguación", pero no hay razón para mostrarlos en la parte superior de la página del artículo, donde se ven redundantes y un poco tontos. Proponemos que los filtremos fuera de la visualización de la página del artículo y en cualquier otro lugar donde sean innecesarios. Me gustaría conocer más ejemplos de páginas donde las descripciones breves no son útiles, si la gente conoce alguna.
- Para las páginas de artículos, no conozco ningún ejemplo hasta ahora en el que una descripción en blanco sea mejor para las personas que las necesitan (personas que leen, buscan o agregan enlaces en VE). Si vamos a crear la función "mostrar una descripción en blanco", entonces debemos hablar sobre casos de uso específicos en los que ese sería el mejor resultado. Así es como funciona el desarrollo de productos: no crea una función, si no tiene ejemplos de dónde sería útil. Si la gente tiene ejemplos específicos, eso ayudaría mucho. - DannyH (WMF) ( charla ) 14:58, 8 de diciembre de 2017 (UTC)
- "Para las páginas de artículos, no conozco ningún ejemplo hasta ahora en el que una descripción en blanco sea mejor" Revise los dos ejemplos de vandalismo en páginas con más de 10,000 páginas vistas por día que di en esta misma discusión, incluida una infracción de BLP muy flagrante que duró 8 horas hoy. En estos ejemplos, una descripción en blanco hubiera sido preferible a la vandalizada, ¿no? Ambos artículos, por cierto, están semiprotegidos aquí, por lo que los IP no podrían haber cometido actos de vandalismo aquí (y es muy probable que los hubieran detectado mucho antes). "casos de uso específicos en los que ese sería el mejor resultado". = todos los artículos, y ciertamente BLP. Fram ( charla ) 15:19, 8 de diciembre de 2017 (UTC)
- Si desea otro ejemplo de dónde no sería preferible ninguna descripción sobre la de Wikidata, mire a la derecha. Esto es lo que las personas que buscan sobre la Segunda Guerra Mundial (o lo tienen en "artículos relacionados", la aplicación móvil, ... ven ahora mismo y lo han visto desde hace más de 5 horas (sin duda pronto se revertirá ahora que publiqué esto aquí ). Este tipo de cosas sucede todos los días y con demasiada frecuencia en algunas de nuestras páginas más vistas. Fram ( charla ) 15:38, 8 de diciembre de 2017 (UTC)
- Estoy de acuerdo en que la tasa de respuesta al vandalismo en Wikidata a veces es demasiado lenta. Creo que la solución a eso es mejorar la tasa de respuesta, facilitando que los editores de Wikipedia monitoreen y corrijan el vandalismo de las descripciones. No estoy de acuerdo con que la mejor solución sea dejar en blanco las descripciones de forma preventiva porque sabemos que existe la posibilidad de que sean vandalizadas. Estoy pidiendo ejemplos específicos en los que los editores elegirían no mostrar una descripción en la página del artículo, porque una descripción en blanco es mejor que la mayoría de las descripciones buenas a adecuadas que ya están en Wikidata. - DannyH (WMF) ( charla ) 16:10, 8 de diciembre de 2017 (UTC)
- Y estoy diciendo que esto es una pista falsa. En primer lugar, afirma que existe una mayoría de descripciones de buenas a adecuadas en Wikidata, sin ninguna evidencia convincente de que este sea el caso. Estoy afirmando que de varios cientos de descripciones breves que produje, hubo un número distinto de cero de casos en los que una descripción breve no hizo una mejora aparente sobre el título del artículo por sí solo. · · · Peter (Southwood) (charla) : 16:21, 8 de diciembre de 2017 (UTC)
- Estoy de acuerdo en que la tasa de respuesta al vandalismo en Wikidata a veces es demasiado lenta. Creo que la solución a eso es mejorar la tasa de respuesta, facilitando que los editores de Wikipedia monitoreen y corrijan el vandalismo de las descripciones. No estoy de acuerdo con que la mejor solución sea dejar en blanco las descripciones de forma preventiva porque sabemos que existe la posibilidad de que sean vandalizadas. Estoy pidiendo ejemplos específicos en los que los editores elegirían no mostrar una descripción en la página del artículo, porque una descripción en blanco es mejor que la mayoría de las descripciones buenas a adecuadas que ya están en Wikidata. - DannyH (WMF) ( charla ) 16:10, 8 de diciembre de 2017 (UTC)
- DannyH (WMF) , Filtrar descripciones fuera de la vista de la página del artículo significa que serán invisibles para el mantenimiento, lo cual es muy malo , a menos que se filtren en función del contenido, no del tipo de página, lo que puede ser técnicamente problemático. No escribo código de filtro. ¿Puedes garantizar que ningún vandalismo pueda colarse por esta ruta ?. Siempre que estén visibles en cualquier lugar en asociación con el artículo de Wikipedia, son un problema editorial de Wikipedia. · · · Peter (Southwood) (charla) : 15:39, 8 de diciembre de 2017 (UTC)
- No estamos pidiendo que una función de desarrollo omita descripciones que no existen, es el valor predeterminado más simple posible. Intente aceptar que simplemente mostrar cualquier contenido en el parámetro de palabra mágica es la solución más simple y versátil, y que si lo dejamos en blanco es porque preferimos que se deje en blanco. Si alguien prefiere tener una descripción breve en cualquiera de estos casos, puede editar Wikipedia para poner la que crea que es correcta, y si alguien no está de acuerdo lo suficiente como para querer eliminarlo, puede seguir el procedimiento estándar para desacuerdos editoriales, que es obtener consenso en la página de discusión. No es ciencia espacial, es la forma en que Wikipedia hace estas cosas. Si es difícil para la palabra mágica manejar un comentario en el parámetro, simplemente podemos poner el comentario fuera. Puede haber algunos casos más en los que las personas no se den cuenta de que está allí, pero probablemente no sea un accidente de tren. ¿Hay alguna razón por la que un comentario en el espacio de parámetros no deba analizarse como equivalente a ninguna descripción? He preguntado esto antes y todavía estoy esperando una respuesta. · · · Peter (Southwood) (charla) : 15:39, 8 de diciembre de 2017 (UTC)
- Si desea otro ejemplo de dónde no sería preferible ninguna descripción sobre la de Wikidata, mire a la derecha. Esto es lo que las personas que buscan sobre la Segunda Guerra Mundial (o lo tienen en "artículos relacionados", la aplicación móvil, ... ven ahora mismo y lo han visto desde hace más de 5 horas (sin duda pronto se revertirá ahora que publiqué esto aquí ). Este tipo de cosas sucede todos los días y con demasiada frecuencia en algunas de nuestras páginas más vistas. Fram ( charla ) 15:38, 8 de diciembre de 2017 (UTC)
- # 1 - y céntrese en mejorar las descripciones en Wikidata. Mike Peel ( charla ) 15:27, 8 de diciembre de 2017 (UTC)
- Consulte la discusión en Wikipedia_talk: Wikidata / 2017_State_of_affairs # Circular_ "sourcing" _on_Wikidata : publiqué una muestra aleatoria de 1,000 artículos y descripciones, de los cuales solo 1 descripción tenía un error tipográfico y ninguna parecía estar descaradamente mal, aunque el 39% no aún tengo una descripción. Así que agreguemos esas descripciones adicionales / mejoremos las existentes, en lugar de bifurcar el sistema. Gracias. Mike Peel ( charla ) 00:14, 12 de diciembre de 2017 (UTC)
- Esa muestra incluye las muchas descripciones típicas que están bien en Wikidata e inútiles (o al menos muy poco claras) para el lector promedio de enwiki: "Página de desambiguación de Wikimedia" (¿qué es Wikimedia, no debería ser Wikipedia, e incluso entonces, sé Estoy en Wikipedia, y tampoco usamos "artículo de Wikipedia" como descripción para artículos estándar ...) También hay más errores tipográficos ("oficial del Ejército Británico de Esclavitud"), descripciones inútiles ("asentamiento humano", ¿podemos sea un poco más preciso, por favor), redundantes (Shine On (álbum de Ralph Stanley) - "álbum de Ralph Stanley") ... Y el problema básico, que los problemas basados en el idioma no deben mantenerse en Wikidata sino en los idiomas específicos , no es "bifurcar", es recuperar contenido que no pertenece a Wikidata sino a enwiki. Fram ( charla ) 05:45, 12 de diciembre de 2017 (UTC)
- Puede agregar "Descripciones no en inglés" a la lista de problemas de ese ejemplo: "Engels; schilder; 1919; Londen (Engeland); 1984". Fram ( charla ) 06:01, 12 de diciembre de 2017 (UTC)
- Y "el sexo determinado de un animal o una planta. Use Q6581097 para un ser humano masculino" tampoco es realmente adecuado para su uso en enwiki (pero presumiblemente perfecto para Wikidata). Caso de asesinato de Neeraj Grover - "Ejecutivo de televisión" también parece una descripción incorrecta. Stefan Terzić - "Balonmano en equipo" también podría mejorar. Fram ( charla ) 07:56, 12 de diciembre de 2017 (UTC)
- De acuerdo, tal vez 4/1000 tienen errores tipográficos / no están en inglés / están equivocados, eso no está mal. La mayor parte del resto parece ser WP: IDONTLIKEIT (donde diría WP: SOFIXIT en Wikidata, pero no quieres hacer eso). Sí, se está bifurcando: las descripciones actualmente solo existen en Wikidata (nunca las hemos tenido en Wikipedia) y no desaparecerán debido a esto, por lo que desea bifurcarlas, y de alguna manera eso significa los dos los sistemas no se pueden desmontar posteriormente (debido a problemas de licencia). Eso no es útil, especialmente a largo plazo. Mike Peel ( charla ) 19:58, 12 de diciembre de 2017 (UTC)
- Di más de 4 ejemplos, un 40% no tiene una descripción (por lo que difícilmente puede estar equivocado, incluso si muchos de ellos necesitan una descripción), y muchos tienen descripciones que no podemos o no debemos usar. Básicamente, comenzó con un problema de 0.1% en su opinión, cuando en realidad está más cerca del 50%. Indique los problemas de licencia que ve que harían imposible deshacer la bifurcación. Parece que estos no problemas también harían imposible importar las descripciones de Wikidata, ¿no? Me parece una pista falsa. Por cierto, ¿alguna vez te has quejado de la bifurcación cuando Wikidata estaba poblada con millones de elementos de enwiki (y otros idiomas), donde a partir de entonces podrían evolucionar por separado? ¿O la bifurcación es solo un problema cuando se hace de Wikidata a enwiki, y no al revés? Fram ( charla ) 22:28, 12 de diciembre de 2017 (UTC)
- Solo algunos de sus problemas de ejemplo parecen ser problemas reales, el resto son subjetivos. Estás proponiendo que cambiemos al 100% sin descripción, así que no veo cómo puedes discutir sobre el 40% de las descripciones en blanco (y no fueron un problema al comienzo de esta discusión). No estoy diciendo 0,1%, pero ~ 1% parece razonable aquí. Las descripciones de Enwp tienen licencia CC-BY-SA, lo que significa que no se pueden copiar simplemente a Wikidata ya que tiene una licencia CC-0 (y sí, esto no es genial, y tener derechos de autor de las descripciones simples no tiene ningún sentido , pero es lo que es), aunque eso significa que aún podemos copiar de Wikidata aquí si es necesario. Me quejo de que estamos bifurcando cosas aquí para hacer la misma tarea (describir temas), y que estamos tratando de hacerlo usando la herramienta incorrecta (texto libre con trucos) en lugar de una mejor herramienta (una base de datos estructurada) . Mike Peel ( charla ) 23:01, 12 de diciembre de 2017 (UTC)
- Ah, la vieja afirmación de "base de datos estructurada" versus "texto libre con trucos", me preguntaba por qué no se mencionaba todavía. En Wikidata, estás poniendo texto libre en un campo de la base de datos, que luego, en tiempo de ejecución, se lee y se muestra. En enwiki, estás poniendo texto libre en una plantilla de "palabra mágica", que luego, en tiempo de ejecución, se lee y se muestra. Fingir que las descripciones en Wikidata no son texto libre y enwiki son texto libre no es realmente convincente. Sin embargo, la herramienta incorrecta para la tarea es Wikidata, ya que no forma parte del historial de la página enwiki ni del wikitexto y, por lo tanto, no se puede monitorear, proteger adecuadamente ... El único "truco" es el actual, usar Wikidata para hacer algo que enwiki puede hacer mejor (y que filosóficamente también pertenece a enwiki, ya que es un texto basado en el lenguaje, no un valor universalmente aceptado). Fram ( charla ) 07:53, 13 de diciembre de 2017 (UTC)
- Solo algunos de sus problemas de ejemplo parecen ser problemas reales, el resto son subjetivos. Estás proponiendo que cambiemos al 100% sin descripción, así que no veo cómo puedes discutir sobre el 40% de las descripciones en blanco (y no fueron un problema al comienzo de esta discusión). No estoy diciendo 0,1%, pero ~ 1% parece razonable aquí. Las descripciones de Enwp tienen licencia CC-BY-SA, lo que significa que no se pueden copiar simplemente a Wikidata ya que tiene una licencia CC-0 (y sí, esto no es genial, y tener derechos de autor de las descripciones simples no tiene ningún sentido , pero es lo que es), aunque eso significa que aún podemos copiar de Wikidata aquí si es necesario. Me quejo de que estamos bifurcando cosas aquí para hacer la misma tarea (describir temas), y que estamos tratando de hacerlo usando la herramienta incorrecta (texto libre con trucos) en lugar de una mejor herramienta (una base de datos estructurada) . Mike Peel ( charla ) 23:01, 12 de diciembre de 2017 (UTC)
- Di más de 4 ejemplos, un 40% no tiene una descripción (por lo que difícilmente puede estar equivocado, incluso si muchos de ellos necesitan una descripción), y muchos tienen descripciones que no podemos o no debemos usar. Básicamente, comenzó con un problema de 0.1% en su opinión, cuando en realidad está más cerca del 50%. Indique los problemas de licencia que ve que harían imposible deshacer la bifurcación. Parece que estos no problemas también harían imposible importar las descripciones de Wikidata, ¿no? Me parece una pista falsa. Por cierto, ¿alguna vez te has quejado de la bifurcación cuando Wikidata estaba poblada con millones de elementos de enwiki (y otros idiomas), donde a partir de entonces podrían evolucionar por separado? ¿O la bifurcación es solo un problema cuando se hace de Wikidata a enwiki, y no al revés? Fram ( charla ) 22:28, 12 de diciembre de 2017 (UTC)
- De acuerdo, tal vez 4/1000 tienen errores tipográficos / no están en inglés / están equivocados, eso no está mal. La mayor parte del resto parece ser WP: IDONTLIKEIT (donde diría WP: SOFIXIT en Wikidata, pero no quieres hacer eso). Sí, se está bifurcando: las descripciones actualmente solo existen en Wikidata (nunca las hemos tenido en Wikipedia) y no desaparecerán debido a esto, por lo que desea bifurcarlas, y de alguna manera eso significa los dos los sistemas no se pueden desmontar posteriormente (debido a problemas de licencia). Eso no es útil, especialmente a largo plazo. Mike Peel ( charla ) 19:58, 12 de diciembre de 2017 (UTC)
- Consulte la discusión en Wikipedia_talk: Wikidata / 2017_State_of_affairs # Circular_ "sourcing" _on_Wikidata : publiqué una muestra aleatoria de 1,000 artículos y descripciones, de los cuales solo 1 descripción tenía un error tipográfico y ninguna parecía estar descaradamente mal, aunque el 39% no aún tengo una descripción. Así que agreguemos esas descripciones adicionales / mejoremos las existentes, en lugar de bifurcar el sistema. Gracias. Mike Peel ( charla ) 00:14, 12 de diciembre de 2017 (UTC)
- # 2, o transición del # 1 al # 2 . He entablado discusiones importantes con la WMF sobre el tema de las descripciones en la página de discusión sobre el estado de los asuntos de Wikidata / 2017 . La WMF tiene preocupaciones válidas sobre las descripciones en blanco abruptamente, y deberíamos tratar de cooperar en esas preocupaciones. Dejar temporalmente una palabra clave en blanco por defecto en wikidata (# 1) nos dará tiempo para comenzar a llenar las descripciones locales vacías antes de cerrar las descripciones de wikidata (# 2). Pero a la larga mi posición es definitivamente la número 2. Alsee ( charla ) 21:02, 8 de diciembre de 2017 (UTC) Adición de soporte explícito para el n . ° 5 , que esencialmente coincide con mi voto original. Alsee ( charla ) 16:36, 6 de enero de 2018 (UTC)
- Esto podría funcionar. Mientras completamos descripciones breves, siempre que encontremos un artículo que no debería tener una descripción breve, podríamos poner un espacio sin interrupciones para anular una descripción de Wikidata innecesaria. También necesitaremos ver la pantalla real que se muestra en el dispositivo móvil en el escritorio, para que podamos ver lo que estamos haciendo. Siempre que se muestre la descripción breve en uso real en el escritorio, puede que no sea necesario cambiar. Eso reduciría la presión para acelerar el proceso, lo que puede ser algo bueno, pero también puede que no. · · · Peter (Southwood) (charla) : 10:12, 9 de diciembre de 2017 (UTC)
- Alsee , gracias. Me he mantenido al margen de las conversaciones sobre si / cuándo / cómo se usa / completa la palabra mágica, porque creo que esas son las decisiones de contenido que debe tomar la comunidad de WP en inglés. Quiero averiguar cómo podemos llegar al lugar donde los editores de Wikipedia tienen el control editorial adecuado sobre las descripciones breves, sin dañar la experiencia de los lectores y editores que están usando esas descripciones ahora. - DannyH (WMF) ( conversación ) 23:29, 11 de diciembre de 2017 (UTC)
- Puede habilitar una vista del código Q, la descripción breve y el alias a través de este script: [ [4] ] .-- Carwil ( charla ) 13:01, 9 de diciembre de 2017 (UTC)
- Carwil , este es exactamente el tipo de exhibición que tenía en mente. Es fácilmente visible, pero obviamente no forma parte del artículo en sí , ya que se muestra con otros metadatos en un tamaño de texto diferente. Para ser útil, tendría que ser visible para todos los editores que pudieran realizar mejoras en las descripciones de baja calidad, por lo que tendría que ser una pantalla predeterminada en el escritorio. Es posible que esto no sea bien recibido por todos, pero sería útil, tal vez como una opción de exclusión para aquellos que realmente no quieren saberlo. Todavía no se ocupa de los problemas inherentes de tener la descripción en Wikidata, ya que no es Wikipedia y no dictamos las políticas de contenido de Wikidata, controlamos la protección de su página, bloqueamos a sus vándalos, etc., pero nos deja ver qué hay allí. , y arreglarlo es bastante fácil, aunque tal vez estoy sesgado, ya que he trabajado bastante en Wikidata. Me interesaría escuchar las opiniones de personas que no han editado anteriormente Wikidata sobre el uso de este script. Definitivamente puedo recomendarlo a cualquiera que quiera monitorear la descripción de Wikidata. Felicitaciones a Yair rand . · · · Peter (Southwood) (charla) : 16:15, 9 de diciembre de 2017 (UTC)
- Tampoco resuelve el problema de las diferentes necesidades de la descripción. Cuando la descripción de Wikidata no es adecuada para Wikipedia, no debemos cambiarla arbitrariamente si se adapta bien a los propósitos de Wikidata, pero si se va a utilizar para Wikipedia, es posible que tengamos que hacer precisamente eso. · · · Peter (Southwood) (charla) : 16:21, 9 de diciembre de 2017 (UTC)
- Puede habilitar una vista del código Q, la descripción breve y el alias a través de este script: [ [4] ] .-- Carwil ( charla ) 13:01, 9 de diciembre de 2017 (UTC)
- # 2. Se debe evitar cualquier importación de Wikidata porque ese contenido no está sujeto al control ni al consenso editorial de Wikipedia. Sandstein 16:16, 10 de diciembre de 2017 (UTC)
- Sandstein , Mi preferencia personal es que eventualmente todas las descripciones cortas deben ser parte de Wikipedia y no importadas en tiempo de ejecución, sin embargo, como medida provisional, para que las cosas se muevan más rápidamente, veo algo de valor en mostrar inicialmente la descripción de Wikidata como una predeterminado para un parámetro de palabra mágica en blanco, ya que no es peor que lo que WMF ya está haciendo y, en mi opinión, es probable que continúen haciéndolo hasta que crean que las descripciones locales de Wikipedia son mejores en promedio. Si alguien encuentra una descripción de Wikidata en exhibición que no es adecuada, todo lo que tiene que hacer es insertar una mejor en la palabra mágica e inmediatamente se convierte en parte de Wikipedia. Si encuentra una descripción de Wikidata que sea buena, también puede insertarla en la palabra mágica y hacerla local, ya que necesariamente tienen licencia CC0. La única limitación para obtener contenido 100% local es cuánto esfuerzo, como wikipedistas, estamos dispuestos a poner en él. Los partidarios de Wikidata pueden mejorar las descripciones en Wikidata en cambio si eso es lo que prefieren hacer, y siempre que se muestre una buena descripción breve, puede suceder que nadie se sienta lo suficientemente fuerte como para dejar de permitir su uso. Predigo que cada vez que se detecta una descripción vandalizada, la mayoría de los wikipedistas proporcionarán una breve descripción local, por lo que se alentará a cualquiera que esté a favor de usar las descripciones de Wikidata a que descubra cómo reducir el vandalismo y solucionarlo más rápido, lo que mejorará enormemente Wikidata. Todos ganan, tal vez no tanto como cualquiera de los lados preferiría, pero más de lo que podrían de otra manera. Como sucedería, WMF es el que más gana, pero por molesto que esto pueda resultar para algunos, podemos vivir con ello siempre que también tengamos una ganancia neta para Wikipedia y Wikidata. · · · Peter (Southwood) (charla) : 16:58, 10 de diciembre de 2017 (UTC)
- 2 . No tenemos ni la responsabilidad ni la autoridad para hacer cumplir las directrices de WP en un proyecto con políticas diametralmente opuestas. El contenido fuera del control editorial de WP no debería aparecer en nuestras páginas, punto. James ( charla / contribuciones ) 16:34, 11 de diciembre de 2017 (UTC)
- 2 se acerca más a mis puntos de vista, dadas las opciones. Vea mis comentarios en WT: Wikidata / 2017 State of Affairs / Archive 12 y WT: Wikidata / 2017 State of Affairs . Vea también el RfC de marzo ; la mayor parte de lo que se dijo allí es igualmente relevante para la pregunta actual. - Dank ( pulsar para hablar ) 21:01, 11 de diciembre de 2017 (UTC)
- Comentario de WMF : Quiero decir unas palabras sobre el compromiso y el consenso. He estado involucrado en estas discusiones durante casi tres meses y hay algunas cosas en las que he sido constante.
- En primer lugar, reconozco y acepto que la función existente no permite que los editores de Wikipedia tengan control editorial sobre las descripciones, y es demasiado difícil para los editores de Wikipedia ver las descripciones existentes, monitorear los cambios y solucionar problemas cuando surgen. Esos son problemas que deben ser solucionados por el equipo de producto de WMF y / o el equipo de Wikidata.
- Segundo: la forma en que solucionamos este problema no implica que tomemos decisiones editoriales sobre el formato o el contenido. Eso depende de las comunidades de Wikipedia y Wikidata en inglés, y si hay desacuerdo entre las personas de esas comunidades, el control final debería estar ubicado en Wikipedia y no en Wikidata. En otras palabras: cuando creamos la palabra mágica, no vamos a controlar cómo se usa, con qué frecuencia o cuál debe ser el formato. Creo que estos dos puntos están en consonancia con lo que dice la mayoría de la gente aquí.
- La tercera cosa es que no vamos a estar de acuerdo con un curso de acción que resulte en el borrado masivo de descripciones existentes, por un período de tiempo significativo. Reconozco que eso es algo que la mayoría de la gente aquí quiere que construyamos, pero que sería perjudicial para los lectores y editores que usan esas descripciones, y eso importa. Esta solución también debe tener consenso con nosotros, porque somos nosotros quienes la vamos a construir. No estoy diciendo que vayamos a ignorar el consenso de esta discusión; Estoy diciendo que debemos ser parte de ese consenso. - DannyH (WMF) ( conversación ) 15:13, 12 de diciembre de 2017 (UTC)
- ¿Cuántas personas se han quejado en los 8 meses aproximadamente en que las descripciones se han inhabilitado en la vista móvil? "lectores y editores que utilizan esas descripciones": ¿qué editores serían? De todos modos, básicamente no vas a interferir en las decisiones de contenido, a menos que no te guste el resultado. Pero al mismo tiempo, no puede molestarse en proporcionar las herramientas necesarias para patrullar y controlar sus funciones (y su primer punto es bastante discutible cuando esta palabra mágica se activa y funciona como se solicita de todos modos). Que es lo mismo que hiciste (personalmente y como WMF) con Flow, Gather, ... que luego no se cambió, mejoró, se aceptó gradualmente, sino que simplemente se derrumbó en llamas, al mismo tiempo que creó mucha fricción innecesaria. y mala sangre. ¿De verdad ha aprendido algo de esas debacles? La mayoría de las personas aquí realmente quieren tener descripciones, y estas se completarán con bastante rapidez (probablemente en un porcentaje más alto que el que se proporciona ahora en Wikidata). Pero los llenaremos donde sea necesario , y los dejaremos en blanco donde queramos que estén en blanco . En los últimos meses, podría haber sugerido un compromiso, donde "sin palabra mágica" o "palabra mágica sin descripción" significaría "tomar la descripción de wikidata", y la otra significaba "sin descripción". Podrías haber sugerido "después de instalar la palabra mágica, tomaremos un período de transición de tres meses, para ver si las descripciones se completan aquí en enwiki; luego desactivaremos" buscar desc de wikidata "por completo. En cambio, insistió en que la WMF tendría la última palabra y no permitiría espacios en blanco a menos que fuera para una lista de artículos preaprobada por WMF (o grupos de artículos). ¿Por qué? Ni idea. Si la WMF está tan molesta que los lectores deberían obtener descripciones sin importar qué (incluso si muchos, muchos artículos no tienen descripciones de Wikidata de todos modos en primer lugar), entonces deberían contratar y pagar a algunas personas para que las supervisen y se aseguren de que, por ejemplo, Las violaciones flagrantes de BLP no permanecen durante horas o días. Pero obligarnos a mostrar contenido que no sea enwiki en contra de nuestra voluntad y sin proporcionar ninguna ayuda seria para patrullarlo, simplemente no es aceptable. Fram ( charla ) 15:44, 12 de diciembre de 2017 (UTC)
- Fram, esos compromisos son los que estoy pidiendo que discutamos. Me alegro de que los menciones, es una conversación que podemos tener. Hablaré con el equipo de Wikidata la semana que viene sobre el progreso en la construcción de las herramientas de patrullaje y moderación. No tenemos control directo sobre lo que el equipo de Wikidata elige hacer, pero quiero hablar con ellos sobre cómo la falta continua de una forma de monitorear de manera efectiva las descripciones breves está afectando esta conversación, esta comunidad y la función como un entero. Los editores de Wikipedia en inglés deben tener las herramientas para completar y monitorear las descripciones de manera efectiva, y usted debe tener eso en una línea de tiempo que tenga sentido. Necesito hablar con más personas y seguir trabajando para que eso suceda. Hablaré internamente con la gente sobre el período de transición que está sugiriendo. - DannyH (WMF) ( charla ) 16:04, 12 de diciembre de 2017 (UTC)
- Creo que la principal preocupación es la falta de control sobre el contenido de enwp. Actualmente solo hay dos fuentes externas de contenido de enwp sobre las que la comunidad local no tiene control: Commons y Wikidata; Commons ha tardado algunos años en generar un nivel de confianza sobre sus políticas de contenido y dispositivos de seguridad para evitar abusos en enwp a través de Commons. Hoy en día, la única razón por la que el uso de materiales comunes aquí es doble: 1) han demostrado que pueden manejar sus negocios y 2) existen anulaciones locales que son transparentes y fáciles de implementar. Para que Wikidata sea útil y para evitar el tipo de acritud que estamos viendo aquí, necesitaríamos lo MISMO de Wikidata. El punto 1) solo puede ocurrir con el tiempo, y Wikidata es demasiado nuevo para probarse en esa dirección. Los errores recientes al permitir que el vandalismo fuera del sitio en Wikidata se perpetúe en enwp tampoco ayudan. Si la comunidad de enwp se va a sentir bien al permitir que Wikidata sea útil en el futuro, hasta que esa confianza alcance lo que ha logrado Commons, necesitamos el punto 2 más que nada. Es necesario pasar por defecto al control local sobre el control fuera del sitio, y es poco probable que sea viable cualquier política de arriba hacia abajo que elimine el control local, ya sea directamente o como un hecho consumado mediante el control sutil de la tecnología. Si Wikidata puede demostrar su capacidad para ocuparse de su propio negocio de manera confiable durante muchos años, la comunidad local se sentiría mejor al entregarles parte de ese control local, como trabaja ahora con Commons. Pero eso no puede suceder hoy, y no puede suceder si las anulaciones locales no son simples, sólidas y predeterminadas. - Jayron 32 17:32, 12 de diciembre de 2017 (UTC)
- "Los editores de Wikipedia en inglés deben tener las herramientas para completar y monitorear las descripciones de manera efectiva, y usted debe tener eso en una línea de tiempo que tenga sentido". Sabes, has perdido meses haciendo esto al estancar continuamente las discusiones y "malinterpretar" los comentarios (siempre en la misma dirección, lo cual es extraño para los malentendidos reales y en cambio parece una obstrucción intencional). Basta con que nos dará la palabra mágica, y luego tener las herramientas para monitorear las descripciones: cambios recientes, listas de seguimiento, historiales, ... además de herramientas como la protección semi- o total y similares. Incluso podemos crear filtros para verificar estos cambios específicamente. Podemos construir bots para poblarlos. Desde el principio, todos o casi todos los que estaban discutiendo estas cosas con usted han sugerido o declarado estas cosas, usted fue el único (o casi el único) que creó obstáculos y encontró problemas con estas soluciones donde no existían. "Voy a hablar con el equipo de Wikidata la semana que viene sobre el progreso en la construcción de las herramientas de patrullaje y moderación". es total y absolutamente irrelevante para esta discusión, aunque es algo que se necesita urgentemente en general. Patrullar y moderar las descripciones de Wikidata es algo que no vamos a hacer ; patrullaremos y moderaremos las descripciones de ENWIKI, y tenemos las herramientas para hacerlo (es posible que se necesite una conversación si las descripciones se mostrarán en la versión de escritorio o no, esto podría ser una preferencia del usuario, pero eso no es lo que quiere decir ). Por favor, deje de pelear batallas perdidas y continúe con lo que realmente se decidió y se necesita. Fram ( charla ) 17:54, 12 de diciembre de 2017 (UTC)
- Estoy hablando con varios grupos diferentes en este momento: la comunidad aquí, el equipo de producto de WMF y el equipo de Wikidata, y estoy tratando de lograr que todos esos grupos lleguen a un compromiso que les dé a los editores de Wikipedia el control sobre estas descripciones que que necesita, y no da como resultado la supresión masiva de descripciones durante un período de tiempo significativo. Ese es un proceso que lleva tiempo y todavía estoy trabajando con cada uno de esos grupos. Sé que no hay muchas razones para que usted crea o confíe en mí al respecto. Solo digo que eso es lo que estoy haciendo. - DannyH (WMF) ( charla ) 18:02, 12 de diciembre de 2017 (UTC)
- De hecho, no lo hago. Me interesa saber por qué necesitarías hablar con el equipo de Wikidata para encontrar un compromiso sobre algo que no afectará al equipo de Wikidata ni un poco, a menos que aún no estés planeando implementar la solución acordada y dejes que enwiki decida. Como lidiar con. Fram ( charla ) 22:28, 12 de diciembre de 2017 (UTC)
- Fram, estás diciendo "nosotros", "nosotros", etc. aquí con bastante libertad. Por favor, no hable por todos los editores aquí, especialmente cuando presente sus propias opiniones al mismo tiempo. Hay una razón por la que tenemos RfC ... Gracias. Mike Peel ( charla ) 21:11, 12 de diciembre de 2017 (UTC)
- No se preocupe, no estoy hablando por usted. Pero nosotros (enwiki) ya teníamos un RfC sobre esto, y es el consenso desde allí (y cuál es actualmente el consenso en este RfC) lo que estoy defendiendo. De hecho, hay una razón por la que tenemos RfC, y algunos de nosotros respetamos los resultados de esos. Fram ( charla ) 22:28, 12 de diciembre de 2017 (UTC)
- Me alegro de que no hable por mí, pero ¿por qué está tratando de hablar por todos menos por mí? ¿De qué consenso está hablando, este RfC todavía se está ejecutando (aunque me preocupa que los posibles participantes se asusten con estos argumentos en las secciones! Vote)? ¿Y qué consensos me acusas de faltarle el respeto? Mike Peel ( charla ) 22:40, 12 de diciembre de 2017 (UTC)
- FWIW, Fram definitivamente habla por mí. James ( charla / contribuciones ) 23:24, 12 de diciembre de 2017 (UTC)
- Realmente no parece importarle los resultados del RfC anterior en esto, al igual que no respetó el resultado del WHS RfC cuando su solución no era volver a versiones que no eran de Wikidata, sino mover el bot La plantilla se utiliza para una subpágina / Wikidata que era idéntica a la plantilla rechazada. Básicamente, cuando tienes que elegir entre defender el uso de Wikidata en enwiki o respetar los RfC, te decantas por lo primero más que por lo segundo. Fram ( charla ) 07:53, 13 de diciembre de 2017 (UTC)
- Me alegro de que no hable por mí, pero ¿por qué está tratando de hablar por todos menos por mí? ¿De qué consenso está hablando, este RfC todavía se está ejecutando (aunque me preocupa que los posibles participantes se asusten con estos argumentos en las secciones! Vote)? ¿Y qué consensos me acusas de faltarle el respeto? Mike Peel ( charla ) 22:40, 12 de diciembre de 2017 (UTC)
- No se preocupe, no estoy hablando por usted. Pero nosotros (enwiki) ya teníamos un RfC sobre esto, y es el consenso desde allí (y cuál es actualmente el consenso en este RfC) lo que estoy defendiendo. De hecho, hay una razón por la que tenemos RfC, y algunos de nosotros respetamos los resultados de esos. Fram ( charla ) 22:28, 12 de diciembre de 2017 (UTC)
- Estoy hablando con varios grupos diferentes en este momento: la comunidad aquí, el equipo de producto de WMF y el equipo de Wikidata, y estoy tratando de lograr que todos esos grupos lleguen a un compromiso que les dé a los editores de Wikipedia el control sobre estas descripciones que que necesita, y no da como resultado la supresión masiva de descripciones durante un período de tiempo significativo. Ese es un proceso que lleva tiempo y todavía estoy trabajando con cada uno de esos grupos. Sé que no hay muchas razones para que usted crea o confíe en mí al respecto. Solo digo que eso es lo que estoy haciendo. - DannyH (WMF) ( charla ) 18:02, 12 de diciembre de 2017 (UTC)
- Fram, esos compromisos son los que estoy pidiendo que discutamos. Me alegro de que los menciones, es una conversación que podemos tener. Hablaré con el equipo de Wikidata la semana que viene sobre el progreso en la construcción de las herramientas de patrullaje y moderación. No tenemos control directo sobre lo que el equipo de Wikidata elige hacer, pero quiero hablar con ellos sobre cómo la falta continua de una forma de monitorear de manera efectiva las descripciones breves está afectando esta conversación, esta comunidad y la función como un entero. Los editores de Wikipedia en inglés deben tener las herramientas para completar y monitorear las descripciones de manera efectiva, y usted debe tener eso en una línea de tiempo que tenga sentido. Necesito hablar con más personas y seguir trabajando para que eso suceda. Hablaré internamente con la gente sobre el período de transición que está sugiriendo. - DannyH (WMF) ( charla ) 16:04, 12 de diciembre de 2017 (UTC)
- ¿Cuántas personas se han quejado en los 8 meses aproximadamente en que las descripciones se han inhabilitado en la vista móvil? "lectores y editores que utilizan esas descripciones": ¿qué editores serían? De todos modos, básicamente no vas a interferir en las decisiones de contenido, a menos que no te guste el resultado. Pero al mismo tiempo, no puede molestarse en proporcionar las herramientas necesarias para patrullar y controlar sus funciones (y su primer punto es bastante discutible cuando esta palabra mágica se activa y funciona como se solicita de todos modos). Que es lo mismo que hiciste (personalmente y como WMF) con Flow, Gather, ... que luego no se cambió, mejoró, se aceptó gradualmente, sino que simplemente se derrumbó en llamas, al mismo tiempo que creó mucha fricción innecesaria. y mala sangre. ¿De verdad ha aprendido algo de esas debacles? La mayoría de las personas aquí realmente quieren tener descripciones, y estas se completarán con bastante rapidez (probablemente en un porcentaje más alto que el que se proporciona ahora en Wikidata). Pero los llenaremos donde sea necesario , y los dejaremos en blanco donde queramos que estén en blanco . En los últimos meses, podría haber sugerido un compromiso, donde "sin palabra mágica" o "palabra mágica sin descripción" significaría "tomar la descripción de wikidata", y la otra significaba "sin descripción". Podrías haber sugerido "después de instalar la palabra mágica, tomaremos un período de transición de tres meses, para ver si las descripciones se completan aquí en enwiki; luego desactivaremos" buscar desc de wikidata "por completo. En cambio, insistió en que la WMF tendría la última palabra y no permitiría espacios en blanco a menos que fuera para una lista de artículos preaprobada por WMF (o grupos de artículos). ¿Por qué? Ni idea. Si la WMF está tan molesta que los lectores deberían obtener descripciones sin importar qué (incluso si muchos, muchos artículos no tienen descripciones de Wikidata de todos modos en primer lugar), entonces deberían contratar y pagar a algunas personas para que las supervisen y se aseguren de que, por ejemplo, Las violaciones flagrantes de BLP no permanecen durante horas o días. Pero obligarnos a mostrar contenido que no sea enwiki en contra de nuestra voluntad y sin proporcionar ninguna ayuda seria para patrullarlo, simplemente no es aceptable. Fram ( charla ) 15:44, 12 de diciembre de 2017 (UTC)
- ok ... Propongo que a partir de este momento, DannyH , Usuario: Mike Peel y Usuario: Fram , dejen de participar en este RfC. Ustedes tres y sus desacuerdos mutuos están nuevamente dominando completamente la discusión, exactamente lo que advirtió el caso Arbcom. Esto NO ayuda al resultado de esta discusión. - Th e DJ ( hablar • contribuciones ) 14:24, 13 de diciembre de 2017 (UTC)
- # 3 - Esto tiene más sentido para mí por las razones que expuse anteriormente. Solo enmendaría el n. ° 3 diciendo: Inmediatamente rellene una descripción local para cualquier página que esté activamente protegida contra el vandalismo, lo que podría significar solo páginas protegidas, o podría significar (cuando corresponda) páginas sujetas a la aplicación de arbitraje también .-- Carwil ( hablar ) 18:02, 13 de diciembre de 2017 (UTC)
- # 1 Toda esta idea es solo agregar complejidad a un problema bastante pequeño. Cuanta menos duplicación de datos, mejor. Deberíamos enfocarnos en formas de seguir más proyectos, agregar una mirada y enfocarnos en mejores herramientas para seguir el cambio en Wikipedia en lugar de dividir las fuerzas de Wikimedian en todos los proyectos diferentes. La cooperación y el intercambio son la esencia de estos proyectos, no el control, el desafío y la duplicación de datos. TomT0m ( charla ) 16:34, 15 de diciembre de 2017 (UTC)
- # 1 por DannyH. Además, podemos configurar artículos protegidos para que nunca muestren datos de Wikidata. Vale la pena señalar que esta opción te permite ejecutar un bot que coloca "" como descripción para una clase específica de artículos cuando no te gusta el tipo de descripciones que Wikidata muestra para esos artículos. ChristianKl ( charla ) 15:29, 17 de diciembre de 2017 (UTC)
- Para aclarar, ¿su afirmación de que podemos configurar artículos protegidos para que nunca muestren datos de Wikidata basándonos en saber cómo se podría hacer esto, y que es algo razonablemente fácil de hacer, o es una conjetura? Tenga en cuenta cómo WMF utiliza los datos en la pantalla del móvil. Pregunto porque no sé cómo lo hacen, por lo que no puedo predecir qué tan fácil o de otra manera sería bloquear desde el lado de Wikipedia. La lógica ordinaria sugiere que puede que no sea tan fácil, o que ya se habría hecho. · · · Peter (Southwood) (charla) : 04:44, 18 de diciembre de 2017 (UTC)
- Sin la palabra clave mágica activa, no es posible evitar fácilmente la importación. Sin embargo, una vez que se implemente la función, podrá ejecutar un bot con bastante facilidad que cree "palabra clave mágica = ''" para cada artículo que esté protegido o para otras clases de artículos donde existe la creencia de que la clase de artículo no debería importar. Wikidata y es mejor mostrarle al usuario un '' en lugar de la descripción de Wikidata.
- Además, creo que WMF debería codificar una limitación que una vez que Wikipedia semiproteja un artículo, el artículo deja de mostrar información derivada de Wikidata. Eso requeriría algo de trabajo en la WMF, pero si eso es lo que tienen que hacer para lograr un compromiso, creo que estarán felices de brindar esa garantía. ChristianKl ( charla ) 12:31, 18 de diciembre de 2017 (UTC)
- Me alegraría y me sorprendería un poco que WMF ofreciera una garantía. Hasta ahora han tenido mucho cuidado de no comprometerse con nada de lo que hemos solicitado. Lo creeré cuando lo vea. No tengo ningún conocimiento personal de la complejidad de codificar un filtro que verifique si el artículo está protegido o semiprotegido y usarlo para controlar si se usa una descripción de Wikidata que sea lo suficientemente rápida y eficiente para ejecutarse cada vez que se pueda hacer una descripción corta. desplegado. pero supongo que esta es una sobrecarga adicional que WMF preferiría evitar. Requerir dicho software adicional también podría retrasar la implementación de la palabra mágica, lo que sería un gran paso en la dirección equivocada. Esto debe ser simple y eficiente, por lo que los errores se minimizarán y se maximizará la velocidad. Poner un parámetro de cadena en blanco que se muestra como una cadena en blanco es fácil y simple y no requiere codificación adicional complicada. Esto lo puede hacer cualquier administrador que proteja un artículo donde no hay una descripción corta local. · · · Peter (Southwood) (charla) : 16:33, 18 de diciembre de 2017 (UTC)
- ChristianKl , ¿No tendría más sentido producir una descripción para cada artículo protegido, en lugar de producir un espacio en blanco? Estamos hablando de una lista considerablemente más corta que todos los artículos aquí. Entonces tendríamos funcionalidad (lo que WMF dice que quieren) y protección contra el vandalismo en Wikidata .-- Carwil ( charla ) 15:23, 19 de diciembre de 2017 (UTC)
- Estoy de acuerdo con usted en que escribir una descripción en esos casos tiene sentido, pero las personas que votaron # 2 parecen tener la opinión de que esto no es suficiente protección contra el vandalismo en Wikidata y no quieren que se muestre el contenido de Wikidata incluso si el ' palabra mágica 'está vacía. ChristianKl ( charla ) 17:55, 19 de diciembre de 2017 (UTC)
- ChristianKl , ¿No tendría más sentido producir una descripción para cada artículo protegido, en lugar de producir un espacio en blanco? Estamos hablando de una lista considerablemente más corta que todos los artículos aquí. Entonces tendríamos funcionalidad (lo que WMF dice que quieren) y protección contra el vandalismo en Wikidata .-- Carwil ( charla ) 15:23, 19 de diciembre de 2017 (UTC)
- Me alegraría y me sorprendería un poco que WMF ofreciera una garantía. Hasta ahora han tenido mucho cuidado de no comprometerse con nada de lo que hemos solicitado. Lo creeré cuando lo vea. No tengo ningún conocimiento personal de la complejidad de codificar un filtro que verifique si el artículo está protegido o semiprotegido y usarlo para controlar si se usa una descripción de Wikidata que sea lo suficientemente rápida y eficiente para ejecutarse cada vez que se pueda hacer una descripción corta. desplegado. pero supongo que esta es una sobrecarga adicional que WMF preferiría evitar. Requerir dicho software adicional también podría retrasar la implementación de la palabra mágica, lo que sería un gran paso en la dirección equivocada. Esto debe ser simple y eficiente, por lo que los errores se minimizarán y se maximizará la velocidad. Poner un parámetro de cadena en blanco que se muestra como una cadena en blanco es fácil y simple y no requiere codificación adicional complicada. Esto lo puede hacer cualquier administrador que proteja un artículo donde no hay una descripción corta local. · · · Peter (Southwood) (charla) : 16:33, 18 de diciembre de 2017 (UTC)
- Para aclarar, ¿su afirmación de que podemos configurar artículos protegidos para que nunca muestren datos de Wikidata basándonos en saber cómo se podría hacer esto, y que es algo razonablemente fácil de hacer, o es una conjetura? Tenga en cuenta cómo WMF utiliza los datos en la pantalla del móvil. Pregunto porque no sé cómo lo hacen, por lo que no puedo predecir qué tan fácil o de otra manera sería bloquear desde el lado de Wikipedia. La lógica ordinaria sugiere que puede que no sea tan fácil, o que ya se habría hecho. · · · Peter (Southwood) (charla) : 04:44, 18 de diciembre de 2017 (UTC)
- # 1 La mayoría de las veces, para la mayoría de los propósitos, las descripciones de Wikidata están bien. El n. ° 1 proporciona un mecanismo de anulación sensible para los casos en los que existe una sensibilidad particular. Jheald ( charla ) 20:55, 17 de diciembre de 2017 (UTC)
- A menos que tenga un análisis razonablemente sólido en el que basar esta predicción, es especulación. Sin embargo, habrá poca diferencia a largo plazo, ya que será fácil anular las descripciones de Wikidata mediante la palabra mágica. Es solo una cuestión de cuán tedioso sería, dependiendo de qué proporción de 5,5 millones habrá que hacer. · · · Peter (Southwood) (charla) : 04:44, 18 de diciembre de 2017 (UTC)
- # 2 De acuerdo con Alsee. Muy sensato. Las entradas de Wikidata se pueden importar inicialmente, si es necesario. Es más fácil si las cosas se mantienen en la misma área, con la misma comunidad y políticas. Realmente no veo la ventaja de tener cosas en Wikidata: la descripción es diferente para cada idioma. Galobtter ( pingó mió ) 11:54, 19 de diciembre de 2017 (UTC) Peter Southwood hace excelentes puntos prácticos:
una medida provisional, para que las cosas se muevan más rápidamente, veo algo de valor en mostrar inicialmente la descripción de Wikidata como predeterminada para una magia en blanco parámetro de palabra, ya que no es peor que lo que WMF ya está haciendo
. Galobtter ( pingó mió ) 11:58, 19 de diciembre de 2017 (UTC) Anexo, el n. ° 5 es básicamente eso, sí. Lo que importa es que a largo plazo está aquí. Galobtter ( pingó mió ) 07:21, 10 de enero de 2018 (UTC)
- Galobtter: Wikidata tiene una estructura de datos que mantiene descripciones separadas para cada idioma (o al menos cada idioma con una Wikipedia) .-- Carwil ( charla ) 15:23, 19 de diciembre de 2017 (UTC)
- Lo sé, lo que estoy diciendo es por qué tener todo eso cuando es más útil solo para ese idioma wikipedia. Otros datos sobre wikidata son útiles en las wikipedias: números sin procesar, enlaces de idiomas, etc. Galobtter ( pingó mió ) 15:27, 19 de diciembre de 2017 (UTC)
- Si la descripción está definida en el texto del artículo, entonces solo se puede usar en ese artículo, en ese idioma Wikipedia. Si la descripción está en Wikidata, puede acceder a ella desde otros artículos (por ejemplo, artículos de lista) y lugares como Commons (descripciones de categorías sobre el mismo tema que los artículos), o en Wikivoyage, etc. Si está en una estructura de datos como en Wikidata, entonces es mucho más fácil reutilizarlo automáticamente que si estuviera incrustado en un texto de forma libre. Gracias. Mike Peel ( charla ) 15:34, 19 de diciembre de 2017 (UTC)
- La descripción en Wikidata permanecerá disponible, si otros proyectos o entornos quieren usarla y creen que se adapta a su propósito (y pueden acceder a ella mejor que las palabras mágicas de Enwiki). Sin embargo, esto está bastante fuera del alcance de esta discusión, lo que no cambiará nada en Wikidata. Fram ( charla ) 15:47, 19 de diciembre de 2017 (UTC)
- Si la descripción está definida en el texto del artículo, entonces solo se puede usar en ese artículo, en ese idioma Wikipedia. Si la descripción está en Wikidata, puede acceder a ella desde otros artículos (por ejemplo, artículos de lista) y lugares como Commons (descripciones de categorías sobre el mismo tema que los artículos), o en Wikivoyage, etc. Si está en una estructura de datos como en Wikidata, entonces es mucho más fácil reutilizarlo automáticamente que si estuviera incrustado en un texto de forma libre. Gracias. Mike Peel ( charla ) 15:34, 19 de diciembre de 2017 (UTC)
- Lo sé, lo que estoy diciendo es por qué tener todo eso cuando es más útil solo para ese idioma wikipedia. Otros datos sobre wikidata son útiles en las wikipedias: números sin procesar, enlaces de idiomas, etc. Galobtter ( pingó mió ) 15:27, 19 de diciembre de 2017 (UTC)
- Galobtter: Wikidata tiene una estructura de datos que mantiene descripciones separadas para cada idioma (o al menos cada idioma con una Wikipedia) .-- Carwil ( charla ) 15:23, 19 de diciembre de 2017 (UTC)
- 2 porque Wikidata es una mierda y no debería usarse nunca, independientemente de lo bueno que sea en algunos artículos, WMF ha tenido la oportunidad de patrullar ese sitio y hacer algo al respecto; sin embargo, en su lugar, han ignorado las solicitudes una y otra vez, así que se trata de cada vez que hicimos algo nosotros mismos, de todos modos volver al punto usar espacios en blanco es mejor: si alguien agrega una descripción tonta, se revertirá y sin duda se agregará una. - Davey 2010 Feliz Navidad / Feliz año nuevo 23:31, 27 de diciembre de 2017 (UTC)
- Combinación de 2 y 1 : las descripciones de Wikidata están desactivadas (excepto quizás por una breve ejecución) pero posiblemente se mostrarán cuando SÓLO puedan ocurrir cambios en ellas en la lista de seguimiento. Doc James ( charla · contribuciones · correo electrónico ) 06:24, 30 de diciembre de 2017 (UTC)
- 2 , porque necesitamos un control editorial completo sobre este tipo de contenido. Alternativamente, el n. ° 5 como compromiso. Tony Tan · charla 04:21, 17 de enero de 2018 (UTC)
- Estoy convencido de que el vandalismo afecta la forma en que se muestran las descripciones breves en los resultados de búsqueda, lo que me hace reacio a votar por el número 1. Es cierto que no mostrar descripciones sería menos útil para los lectores que buscan un tema menos conocido con títulos / nombres menos reconocibles. Sin embargo, veo el consenso a favor del control local sobre el control central. El número 5 es bueno, pero desactivar las descripciones de Wikidata no es útil. Más bien, habría demasiado trabajo local manualmente y / o por bot. Ya sea el # 2 o el # 5, las descripciones locales serían vandalizadas (¿a menos que estén protegidas de alguna manera?) De la misma manera que Wikidata ha sido vandalizada. Bueno, vayamos por el n . ° 2 para la mayoría de las personas. O también o alternativamente, ¿qué tal # 4 - Tiene las opciones # 1 y # 2 a través de las preferencias del usuario, pero usa # 2 como opción predeterminada ? Si alguien quiere utilizar las descripciones de Wikidata, ¿por qué no ofrecer la opción de "preferencias de usuario"? George Ho ( charla ) 12:23, 24 de enero de 2018 (UTC)
Llenado de espacios en blanco: opción # 5
Haciendo ping a todos los que votaron en el! ¿Qué hacer con espacios en blanco discusión: Francis Schonken , Peter (Southwood) , Th e DJ , Fram , DannyH (WMF) , Mike Peel , Sandstein , James , Dank , Carwil , TomT0m , ChristianKl , Jheald , Galobtter , Davey 2010 , Doc James .
Si el debate se ve como una simple opción n. ° 1 frente a la opción n. ° 2, la situación es bastante desagradable. Según mi recuento, actualmente hay una mayoría para el número 2, sin embargo, no es exactamente abrumador. Por otro lado, el # 1 tiene un apoyo minoritario sustancial, y la WMF es fuertemente reacia a la posibilidad de que las descripciones se borren en masa antes de que podamos repoblar con nuevas descripciones.
Ha habido una discusión sustancial sobre una alternativa que no se presentó en las opciones de RFC originales: una transición del n. ° 1 al n. ° 2. En la etapa inicial, cualquier artículo que carezca de una descripción local continuará dibujando una descripción de Wikidata. Implementamos la nueva palabra clave de descripción y comenzamos a completar descripciones locales que anulan las descripciones de Wikidata. Una vez que hemos construido una base suficiente de descripciones locales, finalizamos la transición desactivando completamente las descripciones de Wikidata.
Creo que varias de las personas mencionadas anteriormente han expresado su apoyo a este tipo de compromiso. Las personas de lados opuestos pueden considerar esto menos que ideal por razones opuestas, sin embargo, espero que todos consideren este plan en un esfuerzo por construir un consenso de compromiso colaborativo. Alsee ( charla ) 16:24, 6 de enero de 2018 (UTC)
- Realmente no me importa cómo se haga la transición (siempre que se haga en unos pocos meses aproximadamente): el objetivo principal es eventualmente tener todo en enwiki y depender poco o nada de wikidata. Galobtter ( pingó mió ) 16:58, 6 de enero de 2018 (UTC)
- Apoyaría a regañadientes una transición siempre que WMF se comprometa con una fecha límite temporal estricta para desactivar las descripciones de Wikidata. James ( charla / contribuciones ) 18:06, 6 de enero de 2018 (UTC)
- Sí, aceptaría este compromiso. Realmente no importa a largo plazo, siempre que WMF se apague cuando los wikipedistas decidan que las descripciones locales son adecuadas. Dependerá de los wikipedistas completar las descripciones. Cualquiera que quiera que las descripciones de Wikidata se cierren antes puede hacerlo agregando descripciones más breves. · · · Peter (Southwood) (charla) : 18:11, 6 de enero de 2018 (UTC)
- Todavía me parece una pérdida de tiempo. Simplemente use las descripciones de Wikidata y mejórelas allí. Mike Peel ( charla ) 19:05, 6 de enero de 2018 (UTC)
- Como discutimos a continuación, el plan de WMF es cambiar de un Wikidata-fallback al control total de enwiki cuando hay 2 millones de descripciones breves que no están en blanco en enwiki, lo que es aproximadamente comparable al número de descripciones existentes en Wikidata. Eso ayudará a garantizar que los lectores y editores que utilicen estas descripciones no noten una degradación repentina de la función. - DannyH (WMF) ( charla ) 19:16, 6 de enero de 2018 (UTC)
- No recuerdo haber visto ningún consenso con respecto a los 2 millones citados anteriormente. · · · Peter (Southwood) (charla) : 15:22, 7 de enero de 2018 (UTC)
- Mientras pienso más en esto, sería realmente más fácil si pudiéramos hacer que ese elemento de Wikidata aparezca en nuestras listas de seguimiento (para aquellos que lo deseen). Que apoyaría simplemente seguir usando WD.
- También sería bueno mostrar las definiciones breves dentro del texto de Wikipedia para aquellos que lo deseen y estén conectados. Doc James ( charla · contribuciones · correo electrónico ) 06:51, 7 de enero de 2018 (UTC)
- Entonces, ese debería ser el predeterminado, esa es la única manera de que la misma cantidad de personas lo miren. También debería ser más visible, apareciendo en algún lugar al editar en enwiki (tal vez incluso "editable" allí) pero almacenado en wikidata. Actualmente es bastante oscuro dónde se almacena; la mayoría de las personas que editan deben saber dónde pueden cambiar la descripción. Entonces es algo razonable. Las objeciones serían un control enwiki sobre ellos. Galobtter ( pingó mió ) 07:00, 7 de enero de 2018 (UTC)
- @ Doc James : Ya estamos a mitad de camino con Preferencias -> Lista de seguimiento -> "Mostrar ediciones de Wikidata en su lista de seguimiento" para ver las ediciones de Wikidata en las listas de seguimiento de enwp, y este javascript para mostrar las descripciones de wikidata en la parte superior de los artículos. Tendría mucho más sentido para mí si dedicamos el tiempo de desarrollo que se dedicaría a esta palabra mágica sin sentido en mejorar esa funcionalidad. Gracias. Mike Peel ( charla ) 07:58, 7 de enero de 2018 (UTC)
- Ah, muy buen script de usuario. Lo he encendido. Doc James ( charla · contribuciones · correo electrónico ) 08:05, 7 de enero de 2018 (UTC)
- Ese guión es bastante agradable; sin embargo, debe ser predeterminado (o al menos mostrar algún lugar al editar) para que la gente pueda detectar el vandalismo. Galobtter ( pingó mió ) 08:09, 7 de enero de 2018 (UTC)
- Mantener la descripción en Wikidata la mantiene bajo el control y las políticas de un proyecto diferente. Es injusto para Wikidata si la Wikipedia en inglés impone sus políticas sobre lo que puede ser contenido en Wikidata, lo que sucederá si las descripciones se almacenan allí. Mover el texto que es específico de un artículo de Wikipedia a Wikipedia evita esa lata de gusanos. · · · Peter (Southwood) (charla) : 15:22, 7 de enero de 2018 (UTC)
- Sí, señalé esa objeción adicional anterior; Definitivamente necesitará políticas de enwp al respecto, aunque no esté seguro de cuánto choque habrá allí. Probablemente tendrá estandarizaciones para él, etc. Galobtter ( pingó mió ) 15:24, 7 de enero de 2018 (UTC)
- Eso no es un factor decisivo para mí. Estoy feliz de editar Wikidata y ayudar a desarrollar políticas si es necesario. Doc James ( charla · contribuciones · correo electrónico ) 03:48, 5 de febrero de 2018 (UTC)
- Sí, señalé esa objeción adicional anterior; Definitivamente necesitará políticas de enwp al respecto, aunque no esté seguro de cuánto choque habrá allí. Probablemente tendrá estandarizaciones para él, etc. Galobtter ( pingó mió ) 15:24, 7 de enero de 2018 (UTC)
- Mantener la descripción en Wikidata la mantiene bajo el control y las políticas de un proyecto diferente. Es injusto para Wikidata si la Wikipedia en inglés impone sus políticas sobre lo que puede ser contenido en Wikidata, lo que sucederá si las descripciones se almacenan allí. Mover el texto que es específico de un artículo de Wikipedia a Wikipedia evita esa lata de gusanos. · · · Peter (Southwood) (charla) : 15:22, 7 de enero de 2018 (UTC)
- Solo tenerlo en nuestras listas de seguimiento no es suficiente. Para empezar, también necesitamos monitorear otros cambios de Wikidata, siempre y cuando se permita usar Wikidata directamente en nuestros artículos (infoboxes, plantillas como "sitio web oficial", control de autoridad), por lo que no solo tendríamos las descripciones en nuestro lista de seguimiento, pero estos otros también (y por el momento y durante mucho tiempo ya todos los cambios irrelevantes también, mientras que algunos relevantes faltan). También debería estar en el historial de la página, debería ser inmediato (ahora, a menudo hay un retraso, a veces de horas, antes de que aparezca en nuestras listas de seguimiento). Y luego están los problemas de protección y bloqueo, ya que Wikidata permite eludir nuestros bloqueos y protecciones. Por último, estas descripciones también están destinadas al uso interno de Wikidata, pero con demasiada frecuencia chocan con nuestro propósito (por ejemplo, las descripciones de la "lista de Wikimedia" o descripciones que incluyen consejos sobre qué número Q utilizar). Enwiki y Wikidata son dos mundos diferentes, con políticas, prácticas y propósitos diferentes, y la mezcla forzada de ellos es una mala idea (ahora y a largo plazo). Fram ( charla ) 10:11, 8 de enero de 2018 (UTC)
- Como discutimos a continuación, el plan de WMF es cambiar de un Wikidata-fallback al control total de enwiki cuando hay 2 millones de descripciones breves que no están en blanco en enwiki, lo que es aproximadamente comparable al número de descripciones existentes en Wikidata. Eso ayudará a garantizar que los lectores y editores que utilicen estas descripciones no noten una degradación repentina de la función. - DannyH (WMF) ( charla ) 19:16, 6 de enero de 2018 (UTC)
- Oponerse a cualquier "compromiso" impuesto por el acoso y la lectura selectiva de WMF. Enwiki debería decidir cuándo desactivar el uso automático de las descripciones de Wikidata, no el WMF. Fram ( charla ) 10:15, 8 de enero de 2018 (UTC)
- Mantengo mi elección original. - Th e DJ ( hablar • contribuciones ) 11:58, 8 de enero de 2018 (UTC)
- Todavía estoy de acuerdo con Mike Peel en esto: el mejor uso del tiempo de los editores de WP sería hacer buenas descripciones que luego también aparezcan en Wikidata. Y el mejor uso del tiempo de los desarrolladores de WMF no es hacer soluciones especiales para en.wp, sino más bien crear herramientas que permitan a todas las Wikipedias monitorear y proteger los campos de descripción breve almacenados en Wikidata. Pero dado que es probable que tengamos un sistema de este tipo, permítame sugerirle: (1) O WMF debería encontrar una manera de congelar inmediatamente las ediciones en descripciones breves de las páginas protegidas y las páginas más visitadas (que pueden ser técnicamente difíciles) O La comunidad en.wp debería hacer un esfuerzo para escribir tales descripciones, insertándolas AMBOS en en.wp usando la palabra mágica y en Wikidata. (2) El sistema de palabras mágicas debe incluir un "espacio en blanco intencional" que sea diferente de un espacio en blanco aún no escrito. La WMF debería contar estos espacios en blanco intencionales como parte de su objetivo de 2 millones. Los miembros de la comunidad solo deben usar este sistema cuando la descripción realmente no agregue nada a la página porque su título ya es claro (3) Las listas y las páginas de desambiguación deben manejarse en una forma específica de contexto (p. Ej., Podría tener sentido que aparezca la "página de desambiguación de Wikipedia" en VisualEditor pero no en una vista móvil o de escritorio de la página) - Carwil ( charla ) 19:15, 9 de enero de 2018 (UTC)
- Durante 12 meses, la descripción de Bo Scarbrough fue "Clemson le dio ese 'l'" - se ha visto más de 140 mil veces (no es oscuro) desde entonces - hasta que lo vi usando ese script que muestra la descripción de wikidata. Vea aquí . 100%, definitivamente es necesario que sea visible, muy visible, en enwiki para que se pueda detectar el vandalismo, si no se almacena en una palabra mágica. Necesita ser visible en el historial del artículo y también hay problemas con protecciones, bloqueos, etc., como señala Fram. Actualmente, la seguridad parece estar en la oscuridad, lo cual es bastante terrible (y también significa que es mucho menos probable que se agreguen descripciones). Creo que por razones como el control de enwiki (y así tener estandarización, pautas de enwiki y hacerlo más adecuado para enwiki) y detectar el vandalismo, debería estar en una palabra mágica. Galobtter ( pingó mió ) 07:29, 10 de enero de 2018 (UTC)
Otra discusión
- No entiendo nada de esto. ¿Podría alguien explicarme esto? Hydra Tacoz ( charla ) 21:49, 18 de diciembre de 2017 (UTC)
- @ Hydra Tacoz : algunos usos de Wikiepdia tienen descripciones breves de artículos (por ejemplo, en la aplicación Wikipedia o para motores de búsqueda). Dónde y cómo obtenemos o almacenamos esta información es lo que se está discutiendo. Un lugar lógico para guardarlo es Wikidata, pero hay algunos problemas con eso. - Justin ( ko a vf ) ❤ T ☮ C ☺ M ☯ 21:55, 18 de diciembre de 2017 (UTC)
- @Koavf | Justin ¡Gracias! Entonces, ¿cómo es Wikidata un lugar seguro? ¿Qué es exactamente Wikidata? Hydra Tacoz ( charla ) 22:04, 18 de diciembre de 2017 (UTC)
- @ Hydra Tacoz : Wikidata es un proyecto hermano de Wikipedia: es una wiki pero no es una enciclopedia como esta, sino un lugar para almacenar datos estructurados. Si no está familiarizado con las bases de datos, puede parecer confuso al principio, pero imagine a un músico (por ejemplo, John Coltrane) y en Wikipedia, escribiríamos una biografía de él, Wikiqoute tendría citas de él y sobre él, Commons tendría fotos o grabaciones de él o sobre él, etc. Wikidata almacenaría datos individuales como su fecha de nacimiento, estado de ciudadanía, sellos de registro firmados, etc. Una función de Wikidata internamente para proyectos como Wikipedia es almacenar descripciones breves del tema, en este caso, algo así como "saxofonista y compositor de jazz estadounidense". - Justin ( ko a vf ) ❤ T ☮ C ☺ M ☯ 22:07, 18 de diciembre de 2017 (UTC)
- Para aclarar: La función de la breve descripción en Wikidata es una función interna de Wikidata. No está, (o no fue originalmente), diseñado para usarse como una descripción de un artículo de Wikipedia para usar cuando se muestra el nombre de un artículo de Wikipedia por un proyecto de Wikimedia que no sea Wikidata. WMF lo usa actualmente para este propósito porque lo consideran la mejor alternativa disponible (prácticamente la única opción distinta de cero existente). La intención es razonable, ya que ayuda a los usuarios a identificar cuál de un grupo seleccionado de artículos es más probable que sea útil, pero tiene el problema de que está fuera del control directo de los editores de Wikipedia de los artículos que se utiliza para describir, y hay problemas con el vandalismo persistente, descripciones inapropiadas o subóptimas, que solo se pueden editar en Wikidata, y que algunos wikipedistas no están interesados en ser obligados a editar y mantener Wikidata para evitar que el vandalismo aparezca en relación con los artículos de Wikipedia. También hay un problema técnico en el sentido de que la descripción breve no es visible actualmente desde la vista de escritorio y no aparece de manera útil en las listas de seguimiento, por lo que el vandalismo puede pasar desapercibido por los wikipedistas. La solución propuesta es proporcionar una breve descripción en Wikipedia para cada artículo que se pueda utilizar para cualquier propósito donde pueda ser útil, y los desarrolladores de WMF dicen que debe hacerse con una nueva "palabra mágica" que, en la medida de lo posible, hacer es como una función de plantilla más eficiente. Si la palabra mágica está inicialmente poblada con espacios en blanco o con descripciones breves de Wikidata es relativamente poco importante a largo plazo, ya que una vez que existe, los wikipedistas pueden ver y cambiar las descripciones breves cuando los editores lo consideren necesario, desde el entorno de edición de Wikipedia. del artículo asociado: la descripción breve será parte del artículo en sí y los cambios aparecerán en las listas de seguimiento. · · · Peter (Southwood) (charla) : 08:22, 19 de diciembre de 2017 (UTC)
- @Koavf | Justin ¡Gracias! Entonces, ¿cómo es Wikidata un lugar seguro? ¿Qué es exactamente Wikidata? Hydra Tacoz ( charla ) 22:04, 18 de diciembre de 2017 (UTC)
- Hydra Tacoz si hace clic en este enlace de búsqueda y escribe Barra en el cuadro de búsqueda (no presione enter) verá una lista de artículos. La primera entrada probablemente será Bar: establecimiento que sirve bebidas alcohólicas para su consumo en el local . Ese texto es la breve descripción que se analiza aquí. Para ayudar a los usuarios de dispositivos móviles de pantalla pequeña, esa descripción aparece en la parte superior de un artículo cuando se lee en la aplicación Wikipedia. También solía aparecer en la vista del navegador móvil. Aparece en la herramienta de enlace en el editor visual y puede aparecer en otro lugar. Ese texto no está escrito en ninguna parte de Wikipedia. Viene de la entrada de Wikidata para bar . Puedes editarlo allí. Como señalaron otros, Wikidata es un proyecto hermano de la familia Wikimedia. Wikidata ha estado creando esas descripciones para su propio uso, y la Fundación decidió que sería conveniente reutilizar esas descripciones aquí. La comunidad de EnWiki se sorprendió bastante cuando nos dimos cuenta de que se agregó y de cómo funciona. Existe la preocupación de que la mayoría de los editores de EnWiki nunca vean esas descripciones, e incluso si las ven, a menudo no saben a quién corregirlas. Existe preocupación / debate sobre qué tan bien la comunidad de Wikidata puede detectar y corregir el vandalismo. Existe la preocupación de que las descripciones no estén sujetas a las políticas de EnWiki, la protección de la página o los bloqueos de usuarios. Las ediciones en wikidata (incluido el vandalismo, la guerra de edición sesgada o de otro modo) evitarán cualquier protección de página que pongamos en el artículo, y es posible que se nos bloquee la edición de una descripción si un administrador de Wikidata no está de acuerdo con las políticas de EnWiki como BLP . Las descripciones destinadas a los propósitos de Wikidata también pueden no siempre ser las más adecuadas para nuestros propósitos. La discusión aquí es para agregar algo como {{descripción | un establecimiento comercial minorista que sirve bebidas alcohólicas}} en la parte superior de nuestros artículos, y usarlo en lugar de las descripciones de Wikidata. Luego, la descripción se puede ver, editar y controlar como cualquier otro wikitexto de artículo. La desventaja es que EnWiki y Wikidata tendrían sistemas paralelos que administran descripciones similares para propósitos similares. Alsee ( charla ) 11:25, 6 de enero de 2018 (UTC)
- @ Hydra Tacoz : algunos usos de Wikiepdia tienen descripciones breves de artículos (por ejemplo, en la aplicación Wikipedia o para motores de búsqueda). Dónde y cómo obtenemos o almacenamos esta información es lo que se está discutiendo. Un lugar lógico para guardarlo es Wikidata, pero hay algunos problemas con eso. - Justin ( ko a vf ) ❤ T ☮ C ☺ M ☯ 21:55, 18 de diciembre de 2017 (UTC)
Propuesta de dos etapas de WMF para descripciones alojadas en Wikipedia
Hemos estado hablando durante mucho tiempo sobre cómo dar a los colaboradores de Wikipedia control editorial sobre las descripciones breves. Tengo un nuevo enfoque para una solución aquí y me gustaría saber qué piensa.
Primero, para establecer de dónde proviene este enfoque:
- Los editores de Wikipedia en inglés deben poder ver, editar y moderar eficazmente las descripciones breves en la web de escritorio y móvil, sin convertirse en editores activos de Wikidata. Eso requiere una integración significativa en las listas de seguimiento y el historial de páginas de Wikipedia. Esas son características en las que está trabajando el equipo de Wikidata, pero no existen actualmente y no tienen una línea de tiempo para ello.
- Las descripciones breves son muy útiles para los lectores de las aplicaciones móviles y para los editores que utilizan VisualEditor, y dejar en blanco una cantidad significativa de descripciones durante un período de tiempo significativo perjudicaría la experiencia de esos lectores y editores.
- Los editores de Wikipedia en inglés deben tomar las decisiones de contenido sobre cómo completar realmente las descripciones, incluida la posibilidad de especificar páginas donde una descripción no sea útil.
Ese último punto es con el que hemos estado luchando durante un tiempo. Estaba pidiendo ejemplos de páginas de artículos que no deberían tener una descripción, y varias personas mencionaron ejemplos en los que el artículo tenía una frase de desambiguación y la descripción breve solo repetía información de esa frase de desambiguación. He aquí algunos ejemplos:
- Walter Lehmann (gimnasta) - gimnasta
- Translucence (álbum de poliestireno) - álbum de poliestireno
- EAR (formato de archivo) - formato de archivo
Dije anteriormente que no creía que la redundancia fuera perjudicial, pero algunas personas señalaron que estaba moviendo los postes de la portería, pidiendo ejemplos y luego diciendo que no importaban. Estaba tratando de tomar decisiones de contenido sobre el formato, y no soy una de las personas que están haciendo el trabajo real de escribirlas y moderarlas. Punto justo.
Así que quería estimar cuántas descripciones útiles hay actualmente, sacando "Página de lista de Wikimedia" y "Página de desambiguación de Wikimedia", y también sacando páginas donde la descripción es simplemente una frase de desambiguación.
La semana pasada, Mike Peel generó una lista de 1,000 artículos y descripciones al azar , lo que nos ayudó a examinar la calidad de las descripciones en una sección representativa de páginas decente. Quería una muestra más grande, así que generamos una lista de 10,000 artículos y descripciones .
Aquí está el desglose de esa muestra más grande de 10,000 artículos aleatorios. Esta es mi definición actual de descripciones "no útiles":
- 39,82% no tiene una descripción breve en Wikidata
- 7.76% tiene descripciones que incluyen "Wikipedia" o "Wikimedia"
- 1.16% tiene una frase de desambiguación en el título del artículo, que está completamente duplicada en la descripción (116 / 10,000, marcada en la página vinculada arriba)
Al juntarlos, se obtiene un 48,75% de descripciones en blanco / no útiles y un 51,25% de descripciones útiles.
Extrapolando eso a 5,5 millones de artículos, sugiere que alrededor de 2,82 millones de artículos de Wikipedia tienen descripciones útiles. (Estoy abierto a continuar iterando sobre la definición de útil versus no útil, si la gente tiene pensamientos al respecto).
Ahora, desde el lado de WMF, lo que queremos evitar es cambiar repentinamente de 2.8 millones de descripciones útiles a un número mucho menor, que es lo que sucedería si construyéramos una palabra mágica que está en blanco por defecto. Eso dañaría la experiencia de los lectores y editores que confían en las descripciones.
Entonces, la solución que propongo es: WMF crea una palabra mágica que los editores de Wikipedia pueden completar con descripciones.
- Etapa 1: Inicialmente, la visualización de las descripciones se extrae de las palabras mágicas alojadas en Wikipedia, pero si no hay una en Wikipedia, o si la de Wikipedia es una versión en blanco, entonces se vuelve a mostrar el contenido alojado en Wikidata. descripción.
- Etapa 2: cuando hay palabras mágicas alojadas en Wikipedia que no están en blanco en una cantidad de artículos que es aproximadamente comparable a 2.8 millones, entonces WMF cambia a extraer solo las palabras mágicas alojadas en Wikipedia, y no recurrimos a Wikidata- descripciones alojadas. En ese momento, las descripciones que los editores de Wikipedia dejan en blanco estarán en blanco en el sitio.
Las decisiones sobre cómo generar ~ 2.8 millones de descripciones las tomarán los editores de Wikipedia, y la línea de tiempo depende de usted. Me interesará ver cómo se desarrolla ese proceso, pero no es nuestro proceso. Nuestro papel es cambiar a descripciones completas alojadas en Wikipedia cuando hay suficientes descripciones para que las personas que las usan no noten una degradación significativa. Entonces esa es la idea.
Una última cosa que quiero decir es que hay muchas personas en el movimiento, incluida la WMF, que creen que una mayor integración e interdependencia entre Wikidata y Wikipedia será clave para el crecimiento y el éxito del movimiento en el futuro. Seguiremos trabajando para ayudar a Wikidata a crear funciones que hagan que la integración sea realista y práctica.
En este momento, Wikidata no tiene las funciones de trabajo que harían que las descripciones breves sean fáciles de ver y moderar en Wikipedia. En el futuro, a medida que el equipo de Wikidata cree ese tipo de funciones, querremos seguir hablando con la gente sobre cómo fomentar la interdependencia productiva entre los dos proyectos. Espero que una resolución positiva en esta pregunta de descripciones breves ayude a mantener la puerta abierta para esas futuras conversaciones. ¿Qué piensas? - DannyH (WMF) ( charla ) 00:32, 22 de diciembre de 2017 (UTC)
- Tengo problemas para seguir esto. Es cierto que no soy el crayón más afilado de la caja, así que ¿podrías ayudar dándote la versión Cliff's Notes de esta propuesta? Shock Brigade Harvester Boris ( charla ) 01:54, 22 de diciembre de 2017 (UTC)
- La WMF afirma, basándose en una muestra de 10,000 artículos y algunas matemáticas dudosas (116 / 10,000 no es 0.01% obviamente, sino 1.16%) que alrededor de 2.8 millones de artículos enwiki tienen descripciones útiles de Wikidata; en base a esto, continuarán usando la descripción de Wikidata cuando no haya una descripción de la palabra mágica enwiki, hasta que enwiki haya poblado 2.8 millones de palabras mágicas. En ese momento, desactivarán "usar la descripción de Wikidata cuando no haya una descripción enwiki" y cambiarán a "mostrar una descripción en blanco cuando no haya una descripción de la palabra mágica enwiki". 08:09, 22 de diciembre de 2017 (UTC)
- Tu recuento es un poco optimista. Aparte del error matemático explicado anteriormente, veo en su muestra "12. en: German International School New York - school". También veo que en el recuento de las desambigaciones, no se cuentan las que no son idénticas, incluso si son menos específicas y útiles que la desambiguación: "3. en: William McAdoo (político de Nueva Jersey) - político estadounidense ", o agregue algo que sea poco útil:" 15. en: Matt Jones (golfista) - golfista profesional ". Eso es 3 de los primeros 15 que no cuentan como descripciones inútiles, o un 20% más. Lo que reduciría sus 2,88 millones a 1,8 millones más o menos ... Fram ( hablar ) 08:09, 22 de diciembre de 2017 (UTC)
- Y las matemáticas de Fram también están mal aquí. Para ser precisos, DannyH (WMF) encontró 116 desambigaciones entre paréntesis no informativas (porque se duplican). Hay 1197 de esos, 116 de los cuales ya se cuentan como defectuosos, por lo que agregar el 20% del resto nos lleva a 116 + 216 = 332. Entonces, las descripciones defectuosas de las citas entre paréntesis son solo el 3.32% del total. Todavía estamos en aproximadamente la mitad de descripciones válidas. (Desde mi perspectiva, "golfista profesional" es más informativo que "golfista" de la misma manera que "político estadounidense" es menos informativo que "político de Nueva Jersey".) - Carwil ( charla ) 12:46, 23 de diciembre de 2017 ( UTC)
- Encontré el 20% de los primeros 15 en general, no el 20% del resto. Por supuesto, nada garantiza que este porcentaje seguirá siendo el mismo en los 10K, pero no es el cálculo que está haciendo. Mi 20% no se trataba solo de desambiguación, por ejemplo, mi primer ejemplo (número 12) no es una desambiguación. Fram ( charla ) 15:03, 23 de diciembre de 2017 (UTC)
- Y las matemáticas de Fram también están mal aquí. Para ser precisos, DannyH (WMF) encontró 116 desambigaciones entre paréntesis no informativas (porque se duplican). Hay 1197 de esos, 116 de los cuales ya se cuentan como defectuosos, por lo que agregar el 20% del resto nos lleva a 116 + 216 = 332. Entonces, las descripciones defectuosas de las citas entre paréntesis son solo el 3.32% del total. Todavía estamos en aproximadamente la mitad de descripciones válidas. (Desde mi perspectiva, "golfista profesional" es más informativo que "golfista" de la misma manera que "político estadounidense" es menos informativo que "político de Nueva Jersey".) - Carwil ( charla ) 12:46, 23 de diciembre de 2017 ( UTC)
- Estoy de acuerdo con Fram en que el análisis estadístico mencionado anteriormente no soporta una inspección minuciosa y afirma un número significativamente inflado de descripciones útiles. En lugar de discutir inútilmente la pista falsa de cuántos son buenos y cuántos son malos, creo que estaríamos mejor si rellenamos la palabra mágica con descripciones de Wikidata al principio, e inmediatamente cambiamos a mostrar solo descripciones de Wikipedia , como entonces. podríamos deshacernos de la basura más fácilmente y estaríamos libres de interferencias y vandalismo impuesto externamente en la fecha más breve posible. Esta ruta también debería reducir la codificación a la complejidad requerida mínima alcanzable, ya que todo lo que tendría que hacer es producir una cadena de descripción de Wikipedia, sin condicionales. Descripción en blanco => Pantalla en blanco, Descripción que no está en blanco => Pantalla que no está en blanco. Esta debería ser la sobrecarga más baja posible con la menor probabilidad de errores, y debería permitirnos comenzar con la reparación antes. Si la descripción de Wikidata es lo suficientemente buena como para que nadie se moleste en mejorarla, entonces puede quedarse. Las descripciones vacías también estarán vacías en Wikidata, por lo que no hay ninguna desventaja. El vandalismo copiado de Wikidata no estará presente en el dispositivo móvil ni en la pantalla VE después de ser eliminado una vez. La basura copiada de Wikidata se puede ver en Wikipedia y eliminar, ya sea proporcionando una descripción breve mejor o simplemente eliminándola. Mucho mejor que continuar extrayendo material dudoso de Wikidata hasta que se haya producido un número algo arbitrario de descripciones que no estén en blanco en Wikipedia. Una vez que se ha definido la sintaxis de la palabra mágica, un solo bot autorizado por los wikipedistas puede completar los artículos, incluso antes de que se haya finalizado el código de visualización. · · · Peter (Southwood) (charla) : 15:01, 22 de diciembre de 2017 (UTC)
- DannyH (WMF) , no creo que su propuesta sea una mejora de lo que he descrito aquí, prolonga la falta de control interno sobre el contenido de Wikipedia innecesariamente y sin ninguna ventaja. · · · Peter (Southwood) (charla) : 15:19, 22 de diciembre de 2017 (UTC)
- Pbsouthwood y Fram : Podemos meternos en las malas hierbas en los duplicados, pero en última instancia, no creo que vaya a proporcionar mucha claridad por la cantidad de tiempo y trabajo que tomaría. Esta es la opción más justa que podemos ofrecer, y no puedo seguir creando nuevas soluciones solo porque usted dice que no es una mejora. Necesitamos llevar esto a una conclusión. - DannyH (WMF) ( conversación ) 17:56, 22 de diciembre de 2017 (UTC)
- DannyH (WMF) , En primer lugar, no tengo idea de lo que se supone que significa "meterse en las malas hierbas en duplicados", así que no puedo comentar más sobre ello. En segundo lugar, no creo que sea una opción más justa que la que he descrito, dependiendo de cómo se defina "justo" en este caso. En tercer lugar, no veo que sus opciones sean en realidad "soluciones". Soluciones parciales, quizás. Compromisos, sí, pero también lo son la mayoría de las otras opciones discutidas. Creo que estás perdiendo el punto de nuevo. Lea mi sugerencia anterior y, en lugar de un despido general, explique dónde tiene problemas técnicos y cuáles son. · · · Peter (Southwood) (charla) : 03:40, 23 de diciembre de 2017 (UTC)
- DannyH, ¿dónde dije "no es una mejora"? Solo he comentado tus malos cálculos, eso es todo. Si no puede aceptar ningún comentario, cierre este RfC y declare lo que hará el WMF. Fram ( charla ) 11:11, 23 de diciembre de 2017 (UTC)
- Fram y Pbsouthwood : Hemos estado hablando de esto durante meses, y estoy de acuerdo con muchos puntos que ambos han hecho. Este compromiso que propongo dará como resultado descripciones completamente alojadas en Wikipedia, con control sobre páginas individuales donde los editores de WP piensan que la descripción debería estar en blanco. Esto es lo que dijiste que querías. El único compromiso que pido de su lado es que los editores de Wikipedia escriban las descripciones breves que usted dijo que los editores de Wikipedia quieren escribir. ¿Cree que este es un compromiso aceptable? - DannyH (WMF) ( conversación ) 22:44, 23 de diciembre de 2017 (UTC)
- DannyH (WMF) , El compromiso que está sugiriendo requiere que los wikipedistas produzcan 2.8 millones de descripciones antes de aceptar desactivar Wikidata como la palabra mágica vacía predeterminada, lo que significa que los problemas de vandalismo permanecen durante ese período, que puede ser mucho tiempo, ya que Wikipedia es editada por voluntarios que editarán como y donde ellos elijan. Fram cuestiona la validez de este número, y considero preferible una opción más simple que podría resultar en un cierre mucho más temprano de Wikidata, sin ninguna pérdida de funcionalidad útil para WMF. No ha respondido a mi consulta con respecto a objeciones técnicas, así que ¿debo asumir que no hay ninguna? ¿Ha leído y comprendido mi sugerencia anterior, que ahora he puesto en cursiva para que pueda encontrarla más fácilmente? Estas no son preguntas retóricas, las hago para obtener respuestas que puedan ser relevantes para acercarnos a una solución. No puedo obligarlo a responderlas, pero es posible que descubra que las discusiones se desarrollan de manera más fluida y productiva cuando responde preguntas en lugar de cambiar de tema.
- En respuesta a su pregunta, No, hasta que no haya respondido a nuestras preguntas, no puedo aceptar su propuesta como un compromiso aceptable porque me faltan los datos que considero importantes para tomar esa decisión. Sin embargo, hablo solo por mí. Otros pueden estar de acuerdo o en desacuerdo con mis opiniones y yo seguiré el consenso. Lo que estoy tratando de hacer es llevarnos allí al tener las opciones lo más claras posible. También creo que la mayoría, si no todos, los wikipedistas habituales aquí están haciendo lo mismo. · · · Peter (Southwood) (charla) : 16:57, 24 de diciembre de 2017 (UTC)
- Pbsouthwood , lo que está describiendo arriba está absolutamente dentro de los límites de la propuesta que hice. Podemos desactivar el respaldo de Wikidata cuando hay una cantidad comparable de buenas descripciones alojadas en Wikipedia. No vamos a decidir cómo poblar las palabras mágicas; esas son decisiones de contenido que pueden tomar los editores de Wikipedia. Si la gente quiere copiar todas las descripciones de Wikidata existentes, entonces eso alcanzaría el umbral de descripciones, y podríamos desactivar el respaldo de Wikidata en ese momento. Eso responde tu pregunta? - DannyH (WMF) ( charla ) 18:30, 26 de diciembre de 2017 (UTC)
- DannyH (WMF) , Eso responde en parte a mi pregunta. Si WMF está dispuesto a comprometerse a desactivar el respaldo de Wikidata cuando Wikipedia decide que todas las descripciones aceptables de Wikidata han sido transferidas, o han proporcionado otras mejores, entonces aceptaría la propuesta, pero no si WMF planea esperar un arbitrario y un número mal definido basado en una muestra pequeña y un análisis dudoso. · · · Peter (Southwood) (charla) : 19:01, 26 de diciembre de 2017 (UTC)
- Pbsouthwood , lo que está describiendo arriba está absolutamente dentro de los límites de la propuesta que hice. Podemos desactivar el respaldo de Wikidata cuando hay una cantidad comparable de buenas descripciones alojadas en Wikipedia. No vamos a decidir cómo poblar las palabras mágicas; esas son decisiones de contenido que pueden tomar los editores de Wikipedia. Si la gente quiere copiar todas las descripciones de Wikidata existentes, entonces eso alcanzaría el umbral de descripciones, y podríamos desactivar el respaldo de Wikidata en ese momento. Eso responde tu pregunta? - DannyH (WMF) ( charla ) 18:30, 26 de diciembre de 2017 (UTC)
- Fram y Pbsouthwood : Hemos estado hablando de esto durante meses, y estoy de acuerdo con muchos puntos que ambos han hecho. Este compromiso que propongo dará como resultado descripciones completamente alojadas en Wikipedia, con control sobre páginas individuales donde los editores de WP piensan que la descripción debería estar en blanco. Esto es lo que dijiste que querías. El único compromiso que pido de su lado es que los editores de Wikipedia escriban las descripciones breves que usted dijo que los editores de Wikipedia quieren escribir. ¿Cree que este es un compromiso aceptable? - DannyH (WMF) ( conversación ) 22:44, 23 de diciembre de 2017 (UTC)
- Pbsouthwood y Fram : Podemos meternos en las malas hierbas en los duplicados, pero en última instancia, no creo que vaya a proporcionar mucha claridad por la cantidad de tiempo y trabajo que tomaría. Esta es la opción más justa que podemos ofrecer, y no puedo seguir creando nuevas soluciones solo porque usted dice que no es una mejora. Necesitamos llevar esto a una conclusión. - DannyH (WMF) ( conversación ) 17:56, 22 de diciembre de 2017 (UTC)
- Soporte para la solución de 'dos fases' (llenando las descripciones primero y apagando wikidata más tarde), o copiando las descripciones de wikidata y cerrando wikidata más rápidamente.
Después de revisar las 10k descripciones aleatorias de Wikidata , veo que el cálculo de DannyH de 2.8 millones de descripciones 'útiles' en wikidata es algo sobreestimado. Incluye un pequeño porcentaje que tiene un valor cero y otro pequeño porcentaje con un valor insignificante. Sin embargo, espero que todos tengamos una flexibilidad razonable en el vago umbral para que las descripciones locales sustituyan de manera creíble a las descripciones de wikidata. Alsee ( charla ) 23:02, 27 de diciembre de 2017 (UTC)
- Pbsouthwood y Alsee : Está bien, bien. Sí, podemos trabajar juntos sobre cuál sería el umbral para el cambio. Al principio esperaba que pudiéramos extraer la descripción de cada página (5,5 m), pero la consulta tardaría días en ejecutarse y, de todos modos, quería revisar una muestra a mano. Por eso utilicé los 10,000 aleatorios. Si alguien quiere obtener una mejor estimación de alguna manera, está bien, o simplemente decimos un número redondo como 2 millones. O tal vez alguien tenga una mejor idea de cómo juzgar ese umbral. ¿Qué piensas? - DannyH (WMF) ( conversación ) 21:21, 29 de diciembre de 2017 (UTC)
- DannyH (WMF) , creo que si podemos llegar a un acuerdo sobre una forma razonablemente objetiva de establecer que la utilidad de Wikidata como fuente de descripciones breves se ha agotado de manera efectiva, no tenemos que estar de acuerdo en ningún número específico. En algún momento, los wikipedistas sugerirán que hemos tomado tantas descripciones breves como sea razonablemente posible y sean realmente útiles, y solicitemos el cierre de la reserva de Wikidata. Este punto lo estableceríamos mediante discusión interna y consenso, como es tradicional. En este punto, sugiero que se permita a WMF un período de dos semanas para verificar y mostrar evidencia estadísticamente convincente de que vale la pena el esfuerzo de encontrar y extraer más, y una manera de encontrarlos, o hacer el cierre sin más demora. No hay nada que detenga a cualquiera que piense que buscar las últimas descripciones útiles merece un mayor esfuerzo en cualquier momento después del cierre. Nadie gana regateando por un número específico en ausencia de evidencia confiable. Unas pocas semanas o meses de crear y transferir descripciones breves es probable que inspiren una amplia gama de ideas más útiles sobre cómo estimar el punto de corte. · · · Peter (Southwood) (charla) : 05:08, 30 de diciembre de 2017 (UTC)
- Pbsouthwood , creo que necesitamos algún tipo de gol al que apuntar. Si solo decimos que la comunidad decidirá cuándo siente que está hecho, entonces nos encontraremos exactamente en el mismo lugar, sin importar cuántos meses de distancia estén. Me gustaría tener una línea clara en la que podamos estar de acuerdo, para que podamos pasar por el resto del proceso en una paz amistosa. - DannyH (WMF) ( charla ) 19:08, 1 de enero de 2018 (UTC)
- DannyH (WMF) . Hay dos problemas con esta última propuesta:
- ¿Qué le hace pensar que será más fácil llegar a un número fijo razonable y generalmente aceptable ahora que después?
- ¿Quién va a producir un número creíble sin una evidencia generalmente aceptable de validez estadística o un recuento real? Sus propuestas hasta ahora han parecido ingeniosas. Dudo que los wikipedistas acepten sus sugerencias sin una evidencia bastante convincente, y es usted quien está pidiendo un número fijo, por lo tanto, su carga para encontrar uno que podamos aceptar. Si está tratando de retrasar las cosas tanto como sea posible, este parece un método muy eficaz para obstaculizar cualquier progreso. · · · Peter (Southwood) (charla) : 05:16, 2 de enero de 2018 (UTC)
- Confirme que el desarrollo de la palabra mágica no se demorará hasta que se tome una decisión final sobre los números. · · · Peter (Southwood) (charla) : 05:16, 2 de enero de 2018 (UTC)
- Pbsouthwood , ambos estamos operando de buena fe aquí. Publiqué una lista de 10k descripciones aleatorias de Wikidata , con una explicación de la metodología que usé para llegar a una estimación de 2.8 millones de descripciones útiles. He marcado todas las descripciones en esa lista de 10,000 que solo repiten información de la frase de desambiguación, sin contarlas. Si alguien más quiere revisarlo y marcar los que creen que me perdí, está bien, y ajustaré la estimación.
- Lo que estamos midiendo es parcialmente una decisión de juicio, ¿qué cuenta como una repetición de la frase de desambiguación? - por lo que no es una tarea que un script pueda realizar con precisión. Necesita una persona que pueda pasar por descripciones y hacer ese juicio. He hecho eso para 10,000 descripciones y me tomó un par de horas. No puedo dedicar más tiempo a mirar una muestra más grande.
- El desarrollo de la palabra mágica no se demorará hasta que se tome una decisión final sobre los números. Construiremos la palabra mágica que anula la descripción de Wikidata. Hacer el cambio para apagar las descripciones de Wikidata y solo extraer de las descripciones de Wikipedia dependerá del número del que estamos hablando. Estoy sugiriendo 2 millones de descripciones, que es significativamente menor que mi estimación de descripciones existentes. - DannyH (WMF) ( charla ) 18:58, 2 de enero de 2018 (UTC)
- DannyH (WMF) , en mi vida personal no soy un fanático de grabar en piedra detalles a largo plazo, y la comunidad wiki también generalmente se ocupa de las cosas sobre la marcha. Si las descripciones se completan rápidamente, cualquier número objetivo no importará mucho. Si las cosas avanzan con demasiada lentitud, probablemente se justifique algún tipo de examen de lo que está sucediendo de todos modos. Sin embargo, puedo entender que algunas personas pueden sentirse más cómodas si hay un objetivo claro establecido. Si es importante, supongo que podría firmar en un objetivo de 2 millones o antes. Si es necesario, siempre podríamos alcanzar ese objetivo copiando las descripciones de wikidata. Alsee ( charla ) 18:35, 5 de enero de 2018 (UTC)
- Alsee , creo que es útil tener una estimación a la que apuntar, para que la comunidad pueda tomar el tipo de decisión a la que te refieres: ¿necesitamos copiar las descripciones de Wikidata o deberíamos intentar escribirlas todas nosotros mismos? "Necesitamos escribir 2 millones de descripciones" es muy diferente de "necesitamos escribir muchas descripciones". - DannyH (WMF) ( conversación ) 22:40, 5 de enero de 2018 (UTC)
- DannyH (WMF) , en mi vida personal no soy un fanático de grabar en piedra detalles a largo plazo, y la comunidad wiki también generalmente se ocupa de las cosas sobre la marcha. Si las descripciones se completan rápidamente, cualquier número objetivo no importará mucho. Si las cosas avanzan con demasiada lentitud, probablemente se justifique algún tipo de examen de lo que está sucediendo de todos modos. Sin embargo, puedo entender que algunas personas pueden sentirse más cómodas si hay un objetivo claro establecido. Si es importante, supongo que podría firmar en un objetivo de 2 millones o antes. Si es necesario, siempre podríamos alcanzar ese objetivo copiando las descripciones de wikidata. Alsee ( charla ) 18:35, 5 de enero de 2018 (UTC)
- DannyH (WMF) . Hay dos problemas con esta última propuesta:
- Pbsouthwood , creo que necesitamos algún tipo de gol al que apuntar. Si solo decimos que la comunidad decidirá cuándo siente que está hecho, entonces nos encontraremos exactamente en el mismo lugar, sin importar cuántos meses de distancia estén. Me gustaría tener una línea clara en la que podamos estar de acuerdo, para que podamos pasar por el resto del proceso en una paz amistosa. - DannyH (WMF) ( charla ) 19:08, 1 de enero de 2018 (UTC)
- Alsee , estoy de acuerdo con su análisis y comentario más reciente. · · · Peter (Southwood) (charla) : 05:08, 30 de diciembre de 2017 (UTC)
- DannyH (WMF) , creo que si podemos llegar a un acuerdo sobre una forma razonablemente objetiva de establecer que la utilidad de Wikidata como fuente de descripciones breves se ha agotado de manera efectiva, no tenemos que estar de acuerdo en ningún número específico. En algún momento, los wikipedistas sugerirán que hemos tomado tantas descripciones breves como sea razonablemente posible y sean realmente útiles, y solicitemos el cierre de la reserva de Wikidata. Este punto lo estableceríamos mediante discusión interna y consenso, como es tradicional. En este punto, sugiero que se permita a WMF un período de dos semanas para verificar y mostrar evidencia estadísticamente convincente de que vale la pena el esfuerzo de encontrar y extraer más, y una manera de encontrarlos, o hacer el cierre sin más demora. No hay nada que detenga a cualquiera que piense que buscar las últimas descripciones útiles merece un mayor esfuerzo en cualquier momento después del cierre. Nadie gana regateando por un número específico en ausencia de evidencia confiable. Unas pocas semanas o meses de crear y transferir descripciones breves es probable que inspiren una amplia gama de ideas más útiles sobre cómo estimar el punto de corte. · · · Peter (Southwood) (charla) : 05:08, 30 de diciembre de 2017 (UTC)
- Pbsouthwood y Alsee : Está bien, bien. Sí, podemos trabajar juntos sobre cuál sería el umbral para el cambio. Al principio esperaba que pudiéramos extraer la descripción de cada página (5,5 m), pero la consulta tardaría días en ejecutarse y, de todos modos, quería revisar una muestra a mano. Por eso utilicé los 10,000 aleatorios. Si alguien quiere obtener una mejor estimación de alguna manera, está bien, o simplemente decimos un número redondo como 2 millones. O tal vez alguien tenga una mejor idea de cómo juzgar ese umbral. ¿Qué piensas? - DannyH (WMF) ( conversación ) 21:21, 29 de diciembre de 2017 (UTC)
Este es el bit clave:
Los editores de Wikipedia en inglés deben poder ver, editar y moderar eficazmente las descripciones breves en la web de escritorio y móvil, sin convertirse en editores activos de Wikidata. Eso requiere una integración significativa en las listas de seguimiento y el historial de páginas de Wikipedia. Esas son características en las que está trabajando el equipo de Wikidata, pero no existen actualmente y no tienen una línea de tiempo para ello.
La integración no es posible hasta que se crea esta capacidad. La situación actual nos expone a un vandalismo prolongado y, por tanto, daña nuestra reputación. Doc James ( charla · contribuciones · correo electrónico ) 06:12, 30 de diciembre de 2017 (UTC)
- Estoy de acuerdo con Doc James. Necesitamos control editorial local sobre lo que se muestra en esta Wikipedia. Tony Tan · charla 04:24, 17 de enero de 2018 (UTC)
colocar "nobots" en la página de conversación del usuario inactivo
Sería una buena idea si se coloca {{ nobots }} en las páginas de conversación de los usuarios que no han editado en más de 13 meses. o quizás 12.
Actualmente hay muchos usuarios que se ajustan a este criterio. Y se han suscrito a muchos boletines y demás. Estas cosas son entregadas por bots. Y si el usuario ha configurado un bot para archivar, significa que se están desperdiciando muchos recursos, que se pueden guardar.
Si vamos a colocar {{ nobots }}, creo que deberíamos incluir {{ not around }} también. - usernamekiran (charla) 05:25, 7 de febrero de 2018 (UTC)
- La mayoría de los boletines se envían a través de WP: MMS , no realmente "bots", y MMS no respeta eso. - Charla xaosflux 05:41, 7 de febrero de 2018 (UTC)
- @ Xaosflux : La mayoría de las páginas de conversación de usuarios inactivos con las que me he encontrado están inundadas de mensajes del servicio de comentarios y boletines informativos. No sabía que MMS no respeta a los nobots. ¿Legobot respeta a los nobots? - usernamekiran (charla) 09:00, 7 de febrero de 2018 (UTC)
- Si los usuarios quieren utilizar esta función ellos mismos, pueden hacerlo. De lo contrario, sin embargo, no deberíamos decidir por los usuarios qué significa inactivo y si quieren o no recibir mensajes. - Jayron 32 11:50, 7 de febrero de 2018 (UTC)
- Básicamente esto. Hay muchos beneficios de una cuenta además de editar, y recibir mensajes es solo uno de ellos. ~ Amory ( u • t • c ) 12:04, 7 de febrero de 2018 (UTC)
- Si los usuarios quieren utilizar esta función ellos mismos, pueden hacerlo. De lo contrario, sin embargo, no deberíamos decidir por los usuarios qué significa inactivo y si quieren o no recibir mensajes. - Jayron 32 11:50, 7 de febrero de 2018 (UTC)
- @ Xaosflux : La mayoría de las páginas de conversación de usuarios inactivos con las que me he encontrado están inundadas de mensajes del servicio de comentarios y boletines informativos. No sabía que MMS no respeta a los nobots. ¿Legobot respeta a los nobots? - usernamekiran (charla) 09:00, 7 de febrero de 2018 (UTC)
- No, para eso no es {{ nobots }}. Anomie
⚔ 14:25, 7 de febrero de 2018 (UTC)
- Lo que dijo Anomie básicamente. Por lo que puedo ver, no hay nada de malo con la inundación de TP, el usuario ha optado por recibir dichos mensajes (hasta que no lo hagan) y eso incluye tiempos de inactividad. Además, si va a discutir sobre el desperdicio de recursos, hay áreas que necesitan mucha más eficiencia que ahorrar unos pocos kilobytes que el bot agregará a una página de discusión. - QEDK (桜❄伴) 14:43, 7 de febrero de 2018 (UTC)
Agregue un botón "eliminar todas las páginas de redireccionamiento de la lista de observación"
Más de la mitad de las páginas de mi lista de seguimiento son redireccionamientos, y estoy cansado de que se acumulen en la parte superior cada vez que creo un nuevo lote, luego un bot cambia aproximadamente el 15% porque son redireccionamientos dobles. Dejé de agregar redireccionamientos a mi lista de seguimiento cuando los creo , pero eso no hace nada para corregir los redireccionamientos que ya están en mi lista de seguimiento. ¿Le importaría diferir o discutir conmigo? The N th User 03:01, 30 de enero de 2018 (UTC)
- No es una mala idea, en realidad, ¿qué pasó con la solicitud (que vi en alguna parte) de un botón para eliminar elementos de su lista de seguimiento con un clic? ¿Hay un guión que alguien haya escrito que coloque un botón 'eliminar' junto a los listados en la lista de seguimiento (o similar)? - Insertecleverphraseaquí ( o aquí ) 03:37, 30 de enero de 2018 (UTC)
- @ The Nth User : Intente agregar a su CSS . Luego vaya a Especial: Editar lista de seguimiento . Podrá seleccionar los redireccionamientos por su cursiva. - Izno ( charla ) 04:05, 30 de enero de 2018 (UTC)
.watchlistredir { font-style: italic; }
- @ Izno : Eso funcionó, pero ¿qué pasa con los redireccionamientos de categorías? ¿Le importaría diferir o discutir conmigo?
The N th User 04:19, 30 de enero de 2018 (UTC)
- Redirecciones de categorías suaves, no hay nada que pueda hacer más que adivinar las que deben eliminarse (o eliminarlas a medida que aparecen en su lista de seguimiento).
- Los redireccionamientos de categorías difíciles deben ser capturados por el CSS anterior, pero no lo he verificado. - Izno ( charla ) 04:26, 30 de enero de 2018 (UTC)
- @ Izno : Eso funcionó, pero ¿qué pasa con los redireccionamientos de categorías? ¿Le importaría diferir o discutir conmigo?
The N th User 04:19, 30 de enero de 2018 (UTC)
- Esto no sería un gran problema si los robots de reparación de redireccionamiento doble respetaran la decisión de la comunidad de operar con un retraso (lo que al menos evitaría que "corrijan" redireccionamientos dobles que resultan de movimientos malos rápidamente revertidos), o si el El software Mediawiki respetó el consenso de la comunidad para permitir algunas redirecciones dobles . - Uanfala (charla) 15:18, 3 de febrero de 2018 (UTC)
- Los parches son bienvenidos :) - Th e DJ ( hablar • contribuciones ) 14:50 7 de febrero 2018 (UTC)
categorías
por favor creando categorías para el nacimiento por día ejemplo 15 de noviembre nacimiento - Comentario anterior sin firmar agregado por 5.219.149.1 ( hablar • contribuciones )
- Vea la discusión anterior en Wikipedia: Bot solicita # bot para crear nuevas categorías
- No creo que tales categorías sean viables por WP: COPDEF y varios temas de WP: OVERCAT . - Francis Schonken ( charla ) 14:54, 23 de enero de 2018 (UTC)
- Soporte No hay nada en WP: COPDEF o WP: OVERCAT que prevenga esto, y la fecha de nacimiento es claramente un tema definitorio para la mayoría de las personas, ya sea que se consideren las celebraciones de cumpleaños, los horóscopos o (junto con las fechas de muerte) la capacidad de calcular las edades mediante programación. Las intersecciones de categorías permitirán a los usuarios encontrar listas de personas nacidas en una fecha y año determinados , o que murieron en su cumpleaños, o lo que sea. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 21:38, 30 de enero de 2018 (UTC)
- Soporte No puedo creer que no sea así. Por cierto, son "categorías". SpartaN ( charla ) 21:52, 30 de enero de 2018 (UTC)
- Las categorías serían difíciles de manejar. Tenemos 2897 artículos sobre personas que nacieron el 15 de noviembre. Para hacer accesibles esas categorías, tendría que dividirlas en categorías más pequeñas. Y luego, ¿qué criterio usarías? ¿Año? Mduvekot ( charla ) 22:20, 30 de enero de 2018 (UTC)
- Esa no es una razón para no hacerlo, y tenemos muchas categorías más grandes. Pero si deben dividirse, decida el tamaño máximo de categoría óptimo y luego divídalos por, digamos, siglo o género, o ambos, para lograrlo. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 23:08, 30 de enero de 2018 (UTC)
- Lo que concuerda maravillosamente con nuestros nacimientos preexistentes por categorías de siglo (al menos en las biografías antiguas existen esas categorías). SpartaN ( charla ) 01:46, 31 de enero de 2018 (UTC)
- Esa no es una razón para no hacerlo, y tenemos muchas categorías más grandes. Pero si deben dividirse, decida el tamaño máximo de categoría óptimo y luego divídalos por, digamos, siglo o género, o ambos, para lograrlo. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 23:08, 30 de enero de 2018 (UTC)
- Por favor no . Las categorías de artículos biográficos ya están repletas de trivialidades, esto las empeorará aún más. - Uanfala (conversación) 15:22, 3 de febrero de 2018 (UTC)
- No estoy seguro de que tal categorización sea necesaria. Las categorías de nacimientos y muertes para un año determinado ayudan a los lectores a ver la época histórica en la que vivió una persona, pero no veo cómo esta categorización serviría para tal propósito. Vorbee ( charla ) 20:06, 4 de febrero de 2018 (UTC)
- Esto no será de mucha utilidad. Agregará desorden al artículo y causará más trabajo a los patrulleros. Pero quizás deberíamos poner a disposición una herramienta para buscar personas con un cumpleaños en particular. Graeme Bartlett ( charla ) 06:36, 7 de febrero de 2018 (UTC)
En cierto sentido, ya tenemos esta herramienta. Si escribe una fecha del año en el cuadro de la esquina superior derecha, obtendrá una lista de las personas nacidas en esa fecha del año. Vorbee ( charla ) 19:37, 7 de febrero de 2018 (UTC)
Bot para cambiar el sistema de referencia utilizado
Hola, propongo un bot que pasa de tener las referencias en línea estándar a usar Referencias definidas por lista . Ahora, este es un cambio que no tiene ningún efecto en el wikitexto. En cambio, mueve todas las referencias a su propia sección, para aquellos que no están familiarizados. Claramente, su uso (o no) es puramente estilístico. Por lo tanto, el bot solo operaría este proceso a pedido de un usuario. Creo que este es un proceso valioso, debido a la facilidad con la que los artículos grandes se vuelven inmanejables de otra manera. Por ejemplo, tuve que hacer este cambio para corregir la eliminación de una referencia en otra parte del artículo. El resultado fue que un segundo uso de la referencia quedó huérfano. Es en un artículo grande como este, los mismos artículos que plantean la mayoría de los problemas, que hacer el cambio manualmente es tedioso. Por tanto, propongo mi bot. ∰ Bellezzasolo ✡ Discutir 22:49, 6 de febrero de 2018 (UTC)
- Peligroso como se propone En el papel, esto podría estar bien, pero podría ser un bot potencialmente muy controvertido. Un usuario podría solicitar "Hagamos todos los artículos en la categoría: Física y eso causaría estragos en toda la categoría. No estoy del todo en contra de un bot como este si se implementaran salvaguardias más fuertes. Algo como" después de una discusión sobre la charla del artículo página [o Wikiproject] "/" después de un período WP: SILENCE de 7 días ", el bot puede facilitar la implementación de dicho consenso. Headbomb { t · c · p · b } 23:13, 6 de febrero de 2018 (UTC)
- ¿Deshacer? ¿El bot propuesto podría revertir su acción después del hecho (y después de nuevas ediciones de artículos) si hubiera problemas, o sería necesaria la reversión de la revisión? - Charla xaosflux 23:30, 6 de febrero de 2018 (UTC)
- Comentario Si no hubiera hecho ese cambio usted mismo, el Usuario: AnomieBOT habría venido y lo habría hecho una vez que la gente dejara de editarlo con tanta frecuencia. En cuanto a la propuesta en sí, me gustaría ver un fuerte consenso antes de aprobar un bot, incluso un bot bajo demanda. Anomie
⚔ 00:10, 7 de febrero de 2018 (UTC)
- En respuesta a Headbomb , si se solicitara una categoría al bot, solo arreglaría las referencias en la página de la categoría , ya que imagino que funcionaría.
- En respuesta a Xaosflux , estoy seguro de que el bot podría revertirse al detectar errores; supongo que hay una API para eso, aunque no estoy muy familiarizado. Personalmente, espero que funcione como una herramienta semiautomática con una interfaz de Wikipedia, y no veo ninguna razón por la que los usuarios no deban ser responsables de garantizar la corrección, como con WP: HG . Sería bastante fácil prevenir el abuso limitando el número de páginas que un usuario puede solicitar, según la experiencia.
- En respuesta a Anomie , no me di cuenta de que AnomieBot realizaba esa función.
- ∰ Bellezzasolo ✡ Discutir 00:22, 7 de febrero de 2018 (UTC)
- @ Bellezzasolo : No me refiero simplemente a "volver" a la versión anterior a la edición del bot, quiero decir, si el estilo necesita ser revertido en algún lugar después de que se haya hecho, ¿el bot podría deshacer la conversión del estilo que aplicó programáticamente? ? - Charla xaosflux 00:56, 7 de febrero de 2018 (UTC)
- @ Xaosflux : Estoy seguro de que podría programar eso, es ciertamente posible, aunque puede significar un cambio completo de un estilo a otro si el artículo anterior fue una especie de mezcla de Frankenstein. ∰ Bellezzasolo ✡ Discutir 01:05, 7 de febrero de 2018 (UTC)
- Oh, estoy de acuerdo, y esto no es un "requisito" en este momento, solo estoy pensando si la gente comienza a discutir sobre estilos de referencia. Entiendo que, desde la perspectiva de un bot, la mayoría de las veces debería ser una o la otra. - xaosflux Talk 02:16, 7 de febrero de 2018 (UTC)
- @ Xaosflux : Estoy seguro de que podría programar eso, es ciertamente posible, aunque puede significar un cambio completo de un estilo a otro si el artículo anterior fue una especie de mezcla de Frankenstein. ∰ Bellezzasolo ✡ Discutir 01:05, 7 de febrero de 2018 (UTC)
- @ Bellezzasolo : No me refiero simplemente a "volver" a la versión anterior a la edición del bot, quiero decir, si el estilo necesita ser revertido en algún lugar después de que se haya hecho, ¿el bot podría deshacer la conversión del estilo que aplicó programáticamente? ? - Charla xaosflux 00:56, 7 de febrero de 2018 (UTC)
La propuesta es inconsistente con el siguiente pasaje de WP: CITE [énfasis agregado]:
- Evitando el desorden
- Las referencias en línea pueden inflar significativamente el wikitexto en la ventana de edición y pueden volverse difíciles y confusas. Hay dos métodos principales para evitar el desorden en la ventana de edición:
- Insertar citas breves (ver más abajo) que luego hacen referencia a una lista completa de textos fuente
- Las referencias entre paréntesis (ver más abajo) son un subformato establecido de esto, que renuncia al uso de notas en línea y simplemente coloca la cita corta en el cuerpo principal.
- Usar referencias definidas por lista mediante la recopilación del código de cita completo dentro de la plantilla de la lista de referencias y luego insertarlas en el texto con
etiquetas.
- Insertar citas breves (ver más abajo) que luego hacen referencia a una lista completa de textos fuente
- Al igual que con otros formatos de citas, los artículos no deben someterse a una conversión a gran escala entre formatos sin un consenso para hacerlo.
Por lo tanto, tendría que obtener un consenso para cambiar WP: CITE . Creo que sería una mala idea porque hay varios enfoques posibles para evitar el desorden en cualquier artículo en particular, por lo que las alternativas deben discutirse en la página de discusión del artículo en lugar de emplear un bot. Jc3s5h ( charla ) 02:43, 7 de febrero de 2018 (UTC)
- Oponerse - Lo que dijo Jc3s5h; es decir, existe un consenso de la comunidad de que WP: CITEVAR se aplica a la elección entre en línea y LDR. Además, LDR no es claramente superior a en línea de todos modos. Tiene sus desventajas, incluidas las siguientes.
Cuando los editores eliminan contenido que deja un rechazo sin usar, el software coloca un GRAN aviso de error de cita roja en la sección de referencias. Esto les parece feo a los lectores hasta que un editor lo nota y elimina o comenta la referencia no utilizada. Teniendo en cuenta que la referencia correcta ya es demasiado complicada para la mayoría de los editores, no es razonable pedirles a los editores que verifiquen otros usos del refname y eliminen / comenten el LDR si su eliminación lo deja sin usar.
Luego, a veces, la edición de eliminación original se revierte, y luego tenemos un GRAN aviso de error de cita roja para un nombre de referencia indefinido y una cita rota. Enjuague, repita. Hace años planteé la idea de prevenir este efecto eliminando el GRAN error de citación roja de las referencias no utilizadas, pero no ganó fuerza.
En resumen, hay dos obstáculos principales: CITEVAR y la falta de consenso de la comunidad de que los LDR son un resultado positivo neto. - Mandruss ☎ 03:20, 7 de febrero de 2018 (UTC)
Bien, quizás un área menos polémica que AnomieBOT no cubre entonces:
Un bot para arreglar los LDR no utilizados que resultan en grandes errores rojos en la sección de referencias. Esto funcionaría detectando los errores y luego comentando la referencia ofensiva. Al comentar la referencia, todavía está disponible para su revisión (y, si el artículo se está editando, no desaparece en nadie). Luego publicaría en su página de discusión notificándoles de su acción. ∰ Bellezzasolo ✡ Discutir 04:09, 7 de febrero de 2018 (UTC)
- Mejor alternativa: no genere el gran mensaje rojo en primer lugar. Esto dará como resultado que algunos LDR no utilizados se retengan indefinidamente, desperdiciando un poco de espacio, pero ¿y qué? El mensaje podría reemplazarse por uno rojo diferente y más pequeño que se ve solo si el CSS del usuario registrado contiene una determinada declaración, similar a la primera línea de mi CSS . Luego, los editores interesados en realizar este tipo de limpieza podrían estar atentos a esos mensajes y comentar los LDR no utilizados. (Necesitaríamos encontrar un lugar apropiado para documentar el nuevo control CSS). Los LDR no utilizados ya colocan el artículo en una categoría de seguimiento para su limpieza, la única diferencia sería un mensaje menos visible para un error menor. De cualquier manera, no veo una necesidad imperiosa de un bot. - Mandruss ☎ 05:40, 7 de febrero de 2018 (UTC)
- La razón de los grandes mensajes de error es que esto es algo que debe arreglarse, no algo que deba ocultarse o evitarse. Headbomb { t · c · p · b } 12:02, 7 de febrero de 2018 (UTC)
- Exactamente, solo corrige la referencia. Solo mostrarlo como confirmado automáticamente puede ser un argumento, pero deshabilitar la referencia va completamente en contra del punto de los errores (quiero decir, simplemente NO podríamos generar ningún contenido si hay algún error, y eso tendría el mismo efecto que comentarlo , pero hay una razón por la que no hacemos eso). - Th e DJ ( hablar • contribuciones ) 14:45 7 de febrero 2018 (UTC)
- @ TheDJ : Lo siento, no te sigo. Que hace
simplemente fije la
media dereferencia
en el contexto de una referencia no utilizada? En la mayoría de los casos, el LDR dejó de usarse cuando se eliminó el contenido que lo usaba. ¿Cómo es esto un "error" en cuanto a verificabilidad? Entiende que no estamos hablando de nombres de referencia indefinidos en las citas, ¿verdad? - Mandruss ☎ 20:09, 7 de febrero de 2018 (UTC)
- @ TheDJ : Lo siento, no te sigo. Que hace
- Exactamente, solo corrige la referencia. Solo mostrarlo como confirmado automáticamente puede ser un argumento, pero deshabilitar la referencia va completamente en contra del punto de los errores (quiero decir, simplemente NO podríamos generar ningún contenido si hay algún error, y eso tendría el mismo efecto que comentarlo , pero hay una razón por la que no hacemos eso). - Th e DJ ( hablar • contribuciones ) 14:45 7 de febrero 2018 (UTC)
- La razón de los grandes mensajes de error es que esto es algo que debe arreglarse, no algo que deba ocultarse o evitarse. Headbomb { t · c · p · b } 12:02, 7 de febrero de 2018 (UTC)
Plantilla: bot de reducción no libre
(copiado de la charla de Wikipedia: Contenido no gratuito / Archivo 68 # Sugerencia para un nuevo bot ya que no hay muchos colaboradores]]
Me gustaría proponer un nuevo bot para etiquetar todas las nuevas imágenes no libres de gran tamaño con {{ non-free reduce }}. Me gustaría explicar un poco la historia de esta idea, y cuántas imágenes puede afectar.
- En octubre de 2016, había aproximadamente 550,000 imágenes no libres de las cuales aproximadamente 300,000 eran mayores que las pautas de la NFCC, ¡aunque no fue posible encontrarlas fácilmente! Al mismo tiempo, wiki realizó cambios en el motor de búsqueda (consulte mw: Ayuda: CirrusSearch # File_properties_search ), lo que le permite buscar en varios parámetros de archivo (ancho, largo, resolución, donde los programadores han decidido que la "resolución" es igual a la raíz cuadrada del recuento de píxeles: extraño pero cierto). Después de ese cambio, ha sido posible trabajar lentamente a través de este número extraordinariamente grande, y ahora hay alrededor de 600,000 imágenes no libres, de las cuales hay menos de 1000 que están sobredimensionadas (por varias razones) - ver Categoría: Imágenes no libres etiquetado para no reducción , aunque creo que algunos de estos están un poco "jugando al sistema" y podrían reducirse, pero es una minoría muy pequeña.
- Durante este tiempo, se ha hecho evidente que todos los días, por lo general, se cargan alrededor de 70 a 80 imágenes nuevas, de gran tamaño y no gratuitas. La mayoría de estos (alrededor del 80%) son completamente nuevos, y el resto son imágenes actualizadas. Aproximadamente el 10% ya tiene {{ non-free reduce }} agregado por la persona que subió el video, pero la mayoría no está marcada de ninguna manera. Puede encontrar una lista de las cargas de los últimos 7 días (excluidas las que el usuario que subió el video etiquetado inmediatamente para su reducción) se puede encontrar en Usuario: Ronhjones / 7days
- Por lo tanto, la propuesta de apuntar a estas cargas nuevas y sin etiquetar, dentro de un día de carga. Por lo tanto, sabemos que el cargador está activo y, por lo tanto, podemos discutir el tamaño, si corresponde. Un nuevo bot (lo he escrito más o menos, pero no probado) podría
- Usando el motor de búsqueda wiki, busque todas las imágenes con un archivo: > = 325 (105625 píxeles; los bots de reducción no se reducirán por debajo de 105,000 píxeles de todos modos)
- Calcule el recuento de píxeles correcto de la última carga (a diferencia de la búsqueda wiki, que también encuentra versiones anteriores si aún no es RevDel.) Y omita si el tamaño es correcto.
- Compruebe la presencia de {{ non-free reduce }}; {{ no gratuito sin reducción }}; {{ Permiso OTRS }}: si hay alguno, omítalo.
- Agrega {{ non-free reduce }} en la parte superior de la página.
- Agregue una plantilla a la página de discusión de la última persona que subió el video para decir que la imagen se reducirá y por qué, con instrucciones sobre qué hacer y qué no hacer si se necesita una imagen más grande. Posiblemente una opción de plantilla para agregar dependiendo del tipo de archivo (por ejemplo, mapa de bits frente a vector).
Haciendo ping a algunos editores que sé que están interesados en esta área @ BU Rob13 , Stefan2 y Diannaa : Es
hora de discutir un poco ...
- Soporte . Parece una buena idea. Lo único que sugeriría, según la discusión reciente en esta página, sería subir ligeramente el umbral, digamos fileres: > = 380, es decir, reducir solo cuando la reducción es más de aproximadamente un 20% lineal. La cifra de 0,1 Mpx solo pretendía ser una indicación imprecisa; Reducir en menos del 20% me parece demasiado quisquilloso y áspero para la persona que subió el video, ya que un cambio en el tamaño que es prácticamente imperceptible, ciertamente no hace ninguna diferencia legal y puede producir defectos en la calidad de la imagen. Son las imágenes mucho más grandes que esto las que realmente queremos controlar. Pasar a tales imágenes inmediatamente después de la carga, mientras los ojos de quienes las cargan todavía están en ellas, IMO tiene mucho sentido. Jheald ( charla ) 22:16, 30 de enero de 2018 (UTC)
- Qué tan bajo es el umbral es un elemento obvio para lograr un consenso. 316 estaría en la pauta, dije 325 arriba ya que ese es el punto actual en el que los bots reductores dejan de funcionar, 380 es 144400, y eliminaría 79 imágenes de mi lista de 7 días Ron h jones (Discusión) 22:53, 30 de enero 2018 (UTC)
- @ Ronhjones : Un número útil para comparar podría ser el número total de imágenes no gratuitas agregadas en el período. No se puede decir del usuario: Ronhjones / 7days porque solo aparece una lista de imágenes de más de 105625 px.
- Pero sí creo que esto es correcto: las imágenes que son notablemente más grandes de lo normal se reducirían, y de inmediato, mientras se cargan nuevamente; sin ser innecesariamente irritante para los usuarios que subían el contenido que estaban bastante en la norma con cambios que apenas se notarían. Jheald ( conversación ) 23:44, 31 de enero de 2018 (UTC)
- Qué tan bajo es el umbral es un elemento obvio para lograr un consenso. 316 estaría en la pauta, dije 325 arriba ya que ese es el punto actual en el que los bots reductores dejan de funcionar, 380 es 144400, y eliminaría 79 imágenes de mi lista de 7 días Ron h jones (Discusión) 22:53, 30 de enero 2018 (UTC)
- No puedo obtener el número exacto, pero por debajo de "325" es muy pequeño. Una llamada a la API me da 1160 imágenes no gratuitas en esos 7 días, quita mis 498 hojas 662, quita 502 archivos que DatBot redujo es 160, luego quita 91 (SVG que reduje manualmente) dejando 69 imágenes no libres cargadas a continuación " 325 ". ASÍ que las nuevas cargas que estimo son 498 de gran tamaño + 69 de tamaño insuficiente = 567 en total, por lo que el 88% fueron de gran tamaño. Ron h jones (Discusión) 01:40, 1 de febrero de 2018 (UTC)
- (Fin del contenido copiado ) Ron h jones (Discusión) 14:24, 3 de febrero de 2018 (UTC)
- Soporte en principio, no estoy seguro sobre el umbral. עוד מישהו Od Mishehu 09:38, 4 de febrero de 2018 (UTC)
- Es necesario acordar el umbral. Notaré que sea cual sea el umbral que se use, estoy seguro de que habrá usuarios que jugarán con el sistema ; con el bot reductor actual configurado en 105000 píxeles, he visto demasiadas imágenes cargadas a solo una fracción por debajo de eso para ser un coincidencia (y, a menudo, después de una reducción adecuada a <100.000 píxeles, y luego subir una nueva imagen con un comentario de algo como "colores correctos" o "limpiar"). Para las plantillas de asesoramiento (aún no creadas), tengo algunas ideas en Usuario: Ronhjones / Sandbox4 . Ron h jones (Discusión) 14:28, 4 de febrero de 2018 (UTC)
- Consulte también Wikipedia: Bots / Solicitudes de aprobación / Fbot 9 y la discusión de seguimiento en la charla de Wikipedia: Bots / Solicitudes de aprobación / Archivo 9 # Fbot 9 . La gente no estaba contenta cuando un bot estaba etiquetando todos los archivos de gran tamaño. Es posible que esto funcione mejor para las nuevas cargas, ya que es más probable que la persona que subió el video esté activa y sea más probable que note el etiquetado. - Stefan2 ( charla ) 21:00, 5 de febrero de 2018 (UTC)
- De acuerdo, por eso propuse enviar un mensaje al usuario que subió el video. Ron h jones (Discusión) 22:34, 6 de febrero de 2018 (UTC)
- Oponerse ¿Está asumiendo que todas las imágenes son cuadradas? Porque, de lo contrario, su bot marcaría incorrectamente una imagen que fuera, digamos, 400x10, y se perdería una imagen que sea 200x2000. Además, me opondría a cualquier etiquetado de imágenes tan pequeño. 0,1 megapíxeles es una guía, no una política, y el lenguaje utilizado es
Las necesidades pictóricas más comunes pueden satisfacerse con una imagen que no contenga más de unos 100.000 píxeles
(y Masem , quien agregó eso a la directriz, ha dicho que nunca se pretendió que fuera un límite estricto ). Sin embargo, la determinación de si las necesidades pueden ser satisfechas por una imagen de ese tamaño debe ser realizada por un humano, no un bot, y liberar el bot como lo describiste dará como resultado el cambio de tamaño innecesario y con pérdida de las imágenes que podría decirse que cumplen el criterio de "uso mínimo". Si va a hacer esto, diría que el umbral de Fbot 9 de 164,025 debería ser un mínimo absoluto y, francamente, me sentiría más cómodo con un número más cercano a 307,200. Cualquier cosa menos que eso podría ser etiquetada con una etiqueta de "necesita revisión humana", pero no con algo que hará que DatBot aparezca y cambie automáticamente el tamaño de la imagen sin intervención humana. - Ahecht (
PÁGINA DE HABLAR) 23:18, 5 de febrero de 2018 (UTC)
- Fbot9 se refiere a DashBot, que solía dar una imagen bastante más grande, esa tarea fue asumida por el bot de Theo en 2011 (y hace que las imágenes tengan menos de 100.000 píxeles). No entiendo su razonamiento: 400x10 son 4000 píxeles y no se marcarían, 200x2000 son 400.000 píxeles y se marcarían: las imágenes de alta proporción no son la norma actual. El punto principal de la idea es alertar al usuario (que sabemos que está activo) y darle consejos sobre cómo actuar si la imagen necesita un tratamiento especial. Ron h jones (Discusión) 22:31, 6 de febrero de 2018 (UTC)
- Si la idea es alertar al usuario, haga que el bot publique un mensaje en su página de discusión. {{ non-free reduce }} va más allá de solo alertar al usuario, ya que también alertará a un bot para que cambie automáticamente el tamaño de la imagen en 24 horas. - Ahecht (
PÁGINA DE HABLAR) 16:43, 7 de febrero de 2018 (UTC)- Incluso si la reducción es antes de que la persona que subió el video verifique, todavía tienen siete días para revertir, como siempre. Ron h jones (Discusión) 22:46, 7 de febrero de 2018 (UTC)
- Si la idea es alertar al usuario, haga que el bot publique un mensaje en su página de discusión. {{ non-free reduce }} va más allá de solo alertar al usuario, ya que también alertará a un bot para que cambie automáticamente el tamaño de la imagen en 24 horas. - Ahecht (
- Fbot9 se refiere a DashBot, que solía dar una imagen bastante más grande, esa tarea fue asumida por el bot de Theo en 2011 (y hace que las imágenes tengan menos de 100.000 píxeles). No entiendo su razonamiento: 400x10 son 4000 píxeles y no se marcarían, 200x2000 son 400.000 píxeles y se marcarían: las imágenes de alta proporción no son la norma actual. El punto principal de la idea es alertar al usuario (que sabemos que está activo) y darle consejos sobre cómo actuar si la imagen necesita un tratamiento especial. Ron h jones (Discusión) 22:31, 6 de febrero de 2018 (UTC)
- Si existe un bot de este tipo, también debe verificar si el archivo ya se redujo o si la reducción anterior se ha revertido. Hay varias razones para no reducir el tamaño, y no se espera que un bot comprenda la legibilidad o los debates previos sobre el tema. Para nuevas imágenes de gran tamaño sería una actividad útil. Unas cuantas imágenes también calificarían para pd-simple, y aunque estén etiquetadas como uso legítimo, no las necesitan. Sin embargo, otros en realidad se publican con licencias que nos permiten usar un tamaño grande, por ejemplo, CC-BY-ND (o -NC), pero aún no califican para licencias compatibles. Graeme Bartlett ( charla ) 06:27, 7 de febrero de 2018 (UTC)
- Esto solo puede funcionar en nuevas imágenes de gran tamaño, ya que no hay imágenes antiguas de gran tamaño (excepto las que ya están etiquetadas con {{ non-free no reduce }}. Actualmente estoy haciendo el lote de archivos nuevos manualmente cada noche. Estoy asegúrese de que cualquier detalle se pueda resolver en un WP: BRFA Ron h jones (Charla) 22:46, 7 de febrero de 2018 (UTC)
- Metacomment no relacionado ¿Podría cambiarse el título de esta discusión por algo más descriptivo y menos vago? Hay varias discusiones relacionadas con bots al mismo tiempo, y el resto de ellas al menos insinúan su propósito.
{{Anchor|Suggestion for new bot}}
se puede colocar para la continuidad. ~ Tom.Reding ( talk ⋅ dgaf ) 20:51, 9 de febrero de 2018 (UTC)
Proporcionar alguna forma de detectar fácilmente cuándo se eliminan o reducen las controversias o críticas
Hola
He encontrado varios artículos a lo largo de los años en los que las secciones de controversias o críticas de los artículos (principalmente empresas y políticos) han sido eliminadas por editores de IP (muy probablemente que tienen un COI muy directo) con resúmenes de edición inofensivos como 'corrección de estilo' o 'correcciones gramaticales' y no ha sido captado por personas que miran las páginas (o nadie está mirando las páginas).
Me pregunto si hay alguna forma de marcar esto. ¿Quizás pueda haber un bot que verifique dónde se han borrado los títulos de las secciones o grandes trozos de texto relacionados con controversias y críticas y los marca en algún lugar para su revisión?
Gracias
John Cummings ( charla ) 13:10, 11 de febrero de 2018 (UTC)
- Oponerse según Wikipedia: Crítica : en muchos casos, las secciones separadas de Controversias o Críticas son sintomáticas de una mala redacción de artículos (con el "imán de trolls" como síntoma adicional); no depende de un bot imponer una redacción tan mala. Al menos, el bot no sería capaz de distinguir entre los casos en los que las controversias y / o críticas deberían integrarse mejor en la narrativa principal del artículo, y en los que merecen un apartado aparte. La opción de sección separada debería ser una excepción muy rara (aunque de hecho, "imán de trolls"): el hecho de que no sea una excepción demasiado rara habla de la falta de calidad de muchos de estos artículos: la calidad general del artículo es lo que necesita ser abordado en la mayoría de los casos, y de una manera que casi nunca puede ser operado por un bot o asistido por bots Apoyaría un bot que elimine los títulos de las secciones "Controversias" y "Críticas" para aquellos artículos en los que nunca hubo una discusión en la página de discusión sobre si dicha sección separada debería estar presente en primer lugar. Eso sería un poco poco realista como una tarea de bot, pero aún así prefiero apoyar eso que lo que se propone en el OP. - Francis Schonken ( charla ) 13:43, 11 de febrero de 2018 (UTC)
- Esto parece malinterpretar la propuesta, que habla de marcar tales ediciones para revisión humana, no de revertirlas automáticamente. En cuanto al ensayo Wikipedia: crítica , hace puntos válidos sobre el formato y el estilo, pero la realidad es que el diseño de la sección que critica todavía está muy extendido por el momento, y entiendo que la propuesta se trata de detectar eliminaciones de contenido, no cambios de diseño. . Saludos, HaeB ( charla ) 14:56, 11 de febrero de 2018 (UTC)
- Aún así, oponga toda la idea: una edición * comenzando * una sección separada de Controversias o Críticas debe ser marcada, no la edición que trata con la más frecuente sección separada indeseable. En mi humilde opinión, "... todavía está muy extendido ..." es parte del problema (como expliqué anteriormente), no algo para lo que debamos buscar un status quo: la marcación no ocurriría cuando un troll expande una sección de Controversias o Críticas con WP : Detalles INDEBIDOS , pero cuando se eliminara dicho trolling, se marcaría. Un no-no por apoyar demasiado a menudo el contenido y el diseño del artículo deplorable. - Francis Schonken ( charla ) 15:37, 11 de febrero de 2018 (UTC)
- @ Francis Schonken :, lo siento, no estoy siendo claro, estoy buscando formas de marcar para que un humano vea casos en los que se han eliminado controversias y críticas, lo que a menudo lo hacen editores de IP con probable COI ( vea las ediciones de PI del parlamento del Reino Unido como un buen ejemplo de la eliminación continua de información de relaciones públicas durante muchos años ). Estoy sugiriendo que estas secciones comunes son un buen lugar para comenzar a buscar este tipo de actividad, en lugar de ser el único lugar para buscarla (sin importar cómo se sienta acerca de su existencia). - Comentario anterior sin firmar agregado por John Cummings ( charla • contribuciones )
- No, fue perfectamente claro y me opongo, por proteger más bien las críticas de WP: UNDUE que por contrarrestarlas; y no proteger las críticas que se encuentran en el artículo conforme a Wikipedia: guía para las críticas y proteger el contenido (a menudo troll) en una sección separada. El enfoque está desequilibrado hacia los malos hábitos (el "imán de trolls" es un problema mucho más extendido y se estableció como un problema durante mucho más tiempo que los IP eliminando las críticas que pasarían WP: DUE ). - Francis Schonken ( charla ) 17:03, 11 de febrero de 2018 (UTC)
- @ Francis Schonken :, lo siento, no estoy siendo claro, estoy buscando formas de marcar para que un humano vea casos en los que se han eliminado controversias y críticas, lo que a menudo lo hacen editores de IP con probable COI ( vea las ediciones de PI del parlamento del Reino Unido como un buen ejemplo de la eliminación continua de información de relaciones públicas durante muchos años ). Estoy sugiriendo que estas secciones comunes son un buen lugar para comenzar a buscar este tipo de actividad, en lugar de ser el único lugar para buscarla (sin importar cómo se sienta acerca de su existencia). - Comentario anterior sin firmar agregado por John Cummings ( charla • contribuciones )
- Aún así, oponga toda la idea: una edición * comenzando * una sección separada de Controversias o Críticas debe ser marcada, no la edición que trata con la más frecuente sección separada indeseable. En mi humilde opinión, "... todavía está muy extendido ..." es parte del problema (como expliqué anteriormente), no algo para lo que debamos buscar un status quo: la marcación no ocurriría cuando un troll expande una sección de Controversias o Críticas con WP : Detalles INDEBIDOS , pero cuando se eliminara dicho trolling, se marcaría. Un no-no por apoyar demasiado a menudo el contenido y el diseño del artículo deplorable. - Francis Schonken ( charla ) 15:37, 11 de febrero de 2018 (UTC)
- Esto parece malinterpretar la propuesta, que habla de marcar tales ediciones para revisión humana, no de revertirlas automáticamente. En cuanto al ensayo Wikipedia: crítica , hace puntos válidos sobre el formato y el estilo, pero la realidad es que el diseño de la sección que critica todavía está muy extendido por el momento, y entiendo que la propuesta se trata de detectar eliminaciones de contenido, no cambios de diseño. . Saludos, HaeB ( charla ) 14:56, 11 de febrero de 2018 (UTC)
- Estoy de acuerdo en que tales ediciones (con resúmenes de edición engañosos) son un problema. FWIW, ya existen las etiquetas de edición de " borrado de sección" y "referencias eliminadas" . Saludos, HaeB ( charla ) 14:56, 11 de febrero de 2018 (UTC)
- Aún así: más bien protector de la sección separada de Controversias o Críticas, a menudo indeseable, en lugar de abordar el problema del diseño. - Francis Schonken ( charla ) 15:37, 11 de febrero de 2018 (UTC)
- @ Francis Schonken :, aprecio su punto de que las secciones de crítica y controversia pueden estar siendo utilizadas en exceso y, a veces, deberían trasladarse a secciones diferentes , pero esto no es una discusión sobre eso. Es una discusión sobre cómo encontrar una mejor manera de encontrar y marcar para revisión ediciones de COI que eliminan información que es precisa y está dentro del alcance de Wikipedia. Estoy sugiriendo que una forma de sacar a la luz estas ediciones es prestando atención a lo que sucede en estas secciones. Gracias, John Cummings ( charla ) 16:47, 11 de febrero de 2018 (UTC)
- Re "esto no es una discusión sobre eso" - es por eso que el punto debe ser mencionado, mientras que su propuesta se enredaría (es decir, de una manera menos que deseable) con algo que ya es un problema desde hace mucho tiempo. - Francis Schonken ( charla ) 17:03, 11 de febrero de 2018 (UTC)
- @ Francis Schonken :, aprecio su punto de que las secciones de crítica y controversia pueden estar siendo utilizadas en exceso y, a veces, deberían trasladarse a secciones diferentes , pero esto no es una discusión sobre eso. Es una discusión sobre cómo encontrar una mejor manera de encontrar y marcar para revisión ediciones de COI que eliminan información que es precisa y está dentro del alcance de Wikipedia. Estoy sugiriendo que una forma de sacar a la luz estas ediciones es prestando atención a lo que sucede en estas secciones. Gracias, John Cummings ( charla ) 16:47, 11 de febrero de 2018 (UTC)
- Aún así: más bien protector de la sección separada de Controversias o Críticas, a menudo indeseable, en lugar de abordar el problema del diseño. - Francis Schonken ( charla ) 15:37, 11 de febrero de 2018 (UTC)
- Parece una buena idea para un filtro de edición . No creo que esto sea demasiado difícil de implementar, aunque de todos modos podría duplicar el rol de Special: AbuseFilter / 172 . Kb.au ( charla ) 15:06, 11 de febrero de 2018 (UTC)
- Gracias @ Kb.au :, ¿el filtro de supresión de sección existente tiene en cuenta si se elimina toda la sección, incluido el encabezado? John Cummings ( charla ) 16:33, 11 de febrero de 2018 (UTC)
- Específicamente detecta la eliminación de un encabezado de sección. Personalmente, no veo ninguna ventaja en destacar la eliminación de las secciones de Crítica sobre cualquier otra. También estoy de acuerdo con quienes piensan que estas secciones suelen ser problemáticas de todos modos. - zzuuzz (charla) 17:48, 11 de febrero de 2018 (UTC)
- Gracias @ Zzuuzz :, entonces el filtro de abuso ya muestra este tipo de actividad, es solo que la gente no lo está captando. ¿Es que se están realizando demasiadas ediciones para que alguien las vea todas? Puedo ver que algunas de las que he visto podrían verse como ediciones correctas, pero no muchas, pensando en los PM del Reino Unido, por ejemplo, ocurren muchas ediciones en las que la gente intenta eliminar la sección de escándalo de gastos y, a veces, no se revierte. . John Cummings ( charla ) 18:24, 11 de febrero de 2018 (UTC)
- No puedo decir si las personas lo están captando, sabiendo que probablemente lo sean, pero es correcto que ya estén marcadas junto con otras secciones en blanco. ¿Quién puede decir que eliminar una sección de críticas es peor que eliminar una sección con cualquier otro nombre: crítica, elogio, logros u otros? (Observo que "Escándalo de gastos" es un encabezado de sección común para los políticos del Reino Unido). Un filtro de este tipo puede ser útil para detectar secciones problemáticas, pero no me gustaría pensar en él como una 'lista revertida', como se convertiría, que ya sea intencional o no, es precisamente como lo acaba de describir. - zzuuzz (charla) 19:09, 11 de febrero de 2018 (UTC)
- Gracias @ Zzuuzz :, entonces el filtro de abuso ya muestra este tipo de actividad, es solo que la gente no lo está captando. ¿Es que se están realizando demasiadas ediciones para que alguien las vea todas? Puedo ver que algunas de las que he visto podrían verse como ediciones correctas, pero no muchas, pensando en los PM del Reino Unido, por ejemplo, ocurren muchas ediciones en las que la gente intenta eliminar la sección de escándalo de gastos y, a veces, no se revierte. . John Cummings ( charla ) 18:24, 11 de febrero de 2018 (UTC)
- Específicamente detecta la eliminación de un encabezado de sección. Personalmente, no veo ninguna ventaja en destacar la eliminación de las secciones de Crítica sobre cualquier otra. También estoy de acuerdo con quienes piensan que estas secciones suelen ser problemáticas de todos modos. - zzuuzz (charla) 17:48, 11 de febrero de 2018 (UTC)
- Gracias @ Kb.au :, ¿el filtro de supresión de sección existente tiene en cuenta si se elimina toda la sección, incluido el encabezado? John Cummings ( charla ) 16:33, 11 de febrero de 2018 (UTC)
No es una buena idea De todos modos, estas secciones suelen ser una mala idea. North8000 ( conversación ) 18:54, 11 de febrero de 2018 (UTC)
- ¿Está interesado en obtener un filtro de edición de prueba para ver cuál es el alcance del problema? Si los editores están reestructurando controversias, es decir, incorporando otras partes del artículo como se sugiere, eso es una cosa. Pero he visto ediciones de promoción más de una vez que simplemente eliminan ese material. Ejemplos aquí y aquí . Es bastante común que este tipo de trabajo de lavado de wiki se anuncie en una de las bolsas de trabajo. ☆ Bri ( charla ) 19:40, 11 de febrero de 2018 (UTC)
- En el mejor de los casos, las secciones de "Crítica" problemáticas tienden a ser completamente negativas y de peso INDEBIDO, prácticamente en todos los casos. En muchos casos, utilizan frases que dan lo que parece ser un imprimatur de Wikipedia a la "crítica" que es contraria a un montón de políticas. Normalmente vemos " George Gnarph afirma A, pero todo el mundo sabe que A es falso " . Ediciones de tipo. Recoger ( hablar )
Comentario: Quizás una propuesta alternativa para tratar de abordar el mismo problema sería mirar ediciones con una gran cantidad de caracteres eliminados donde aparecen ciertas palabras, por ejemplo, crítica, escándalo, ilegal, condena, etc. John Cummings ( charla ) 09:42, 12 de febrero de 2018 (UTC)
- Re. "... eliminado ...": "... eliminado o agregado ..." Yo diría. Me opondría a cualquier enfoque que simpatice más con la adición de críticas inútiles que con la eliminación de tales críticas. Nuevamente, agregando & WP exagerado : Las críticas INDEBIDAS son, en la mayoría de los casos, el elefante en la sala y, en muchos artículos, el problema más grande. La etiqueta "section blanking", que en general es una buena idea, ya tiene un efecto secundario poco deseable de proteger más bien contra la eliminación de secciones de críticas no deseadas, que contra la creación de tales secciones basadas en verificabilidad poco fiable (a menudo introduciendo WP : Problemas de BLP , etc., en un artículo). Puedo vivir con ese efecto secundario debido a las ventajas generales de ese etiquetado. Pero oponerse a más desequilibrios en los sistemas de mantenimiento que favorecen * las adiciones más problemáticas * sobre las eliminaciones a menudo * menos problemáticas *: actualmente, si alguien fusiona las críticas de una sección separada con la narrativa principal del artículo y elimina el encabezado de la sección indeseable, que se etiqueta como "sección en blanco": no lo presione, diría yo. - Francis Schonken ( charla ) 10:09, 12 de febrero de 2018 (UTC)
Una propuesta para semiproteger permanentemente el espacio Plantilla
- 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.
Después de una serie de ediciones antivandálicas en el espacio de la plantilla ( aquí y aquí , y el ANI al respecto ), MusikAnimal protegió las plantillas ( sin oposición ) con más de 5k transclusiones y semiprotejo todas aquellas con más de 1000 transclusiones.
Hoy temprano, una plantilla con 956 transclusiones fue objeto de vandalismo .
Debido al hecho de que el espacio de la plantilla no está muy vigilado y al potencial de que se produzca un gran daño en muy poco tiempo, propongo que todas las plantillas estén semiprotegidas. Esto probablemente implicaría un cambio de software, pero creo que es la única forma de garantizar que un vandalismo importante en una plantilla relativamente no utilizada no se quede por mucho tiempo, para que lo vea el público desprevenido que tal vez no sepa cómo hacérnoslo saber. arreglarlo.
Discutí brevemente esto fuera de la wiki con Cyberpower678 , quien dijo que apoyarían si hubiera un recuento mínimo de transclusiones (se discutió 10+), por lo que estoy dispuesto a esa opción, pero desde un punto de vista administrativo, creo que es más fácil proteger por lotes. todo (a menos que podamos obtener un robot de protección que pueda autoproteger plantillas con más de 10 transclusiones). Primefac ( charla ) 18:18, 21 de diciembre de 2017 (UTC)
- NOTA: Esto no requeriría un cambio de "software" (para aplicar a un espacio de nombres completo ), pero sí requeriría un cambio de configuración en InitialiseSettings.php . Vea el ejemplo de confirmación automática que se usa para el módulo: espacio de nombres en eswiki (desplácese hasta la parte inferior de la página). - Charla xaosflux 19:30, 21 de diciembre de 2017 (UTC)
- Apoye
todo el espacio conun pequeño número de transclusión, pero no todo el espacio, según el argumento de zzuuzz a continuación. - Insertecleverphraseaquí ( o aquí ) 18:25, 21 de diciembre de 2017 (UTC) - Si. OK, hazlo así. positivo neto - Dlohcierekim ( conversación ) 18:26, 21 de diciembre de 2017 (UTC)
- Soporte Tener un protect-bot es un poco ehh, porque significa que cualquiera puede semi-proteger cualquier plantilla con menos de 10 transclusiones al trasladarla ... no hay mucho potencial de daño allí, pero aún así. Galobtter ( pingó mió ) 18:39, 21 de diciembre de 2017 (UTC)
- Aparte de "ganar" una guerra de edición, no veo cómo sería jugar con el sistema para agregar algunas transclusiones más para dar como resultado semi-prot. Primefac ( charla ) 18:50, 21 de diciembre de 2017 (UTC)
- Quiero decir, ese es un problema vago. Pero raro. Galobtter ( pingó mió ) 03:58, 22 de diciembre de 2017 (UTC)
- Soporte De hecho dije que apoyaré esto y puedo crear fácilmente un bot para hacer cumplir esto. Cuando dije más de 10 transclusiones, quise decir en el espacio de artículos. Así que no hay mucho potencial para los juegos como se mencionó anteriormente.— CYBER POWER ( Feliz Navidad ) 18:42, 21 de diciembre de 2017 (UTC)
- Soporte Neto positivo. Me encantan las direcciones IP y los nuevos editores, pero pueden iniciar sesión y esperar 4 días o simplemente esperar 4 días para editar las plantillas. L3X1 (escritura distænt) 18:53, 21 de diciembre de 2017 (UTC)
- No encuentro convincente el argumento de Zzuzz. "Los calcetines autoconfirmados son fáciles de conseguir" Si se molesta en colocar el mouse sobre el botón para crear una cuenta. Los vándalos que conducen no suelen ser calcetines. Y no pensé que esto se proponía como una cura para los calcetines, solo un vandalismo que puede ser bastante difícil de detectar. Estoy bien para que el límite base se eleve a mil transclusiones o algo así, pero SEMI es un bloqueo antivandálico muy efectivo. Además, la "enciclopedia que cualquiera puede editar" no se aplica aquí. El espacio de la plantilla es el mantenimiento y el marco de la enciclopedia, no el contenido. L3X1 (escritura distænt) 20:19, 21 de diciembre de 2017 (UTC)
- Oh, la cantidad de calcetines autoconfirmados que he bloqueado: estos son vándalos regulares dedicados que hacen esto, no los que conducen por vehículos. Pero ese es un punto menor: no estoy de acuerdo contigo sobre el uso de plantillas. Algunas son, de hecho, plantillas de mantenimiento y de marco (en particular las específicas), pero la gran mayoría de las plantillas (en particular las editadas por usuarios no registrados) contienen listas, nombres y números, y forman parte del contenido. - zzuuzz (charla) 20:36, 21 de diciembre de 2017 (UTC)
- No encuentro convincente el argumento de Zzuzz. "Los calcetines autoconfirmados son fáciles de conseguir" Si se molesta en colocar el mouse sobre el botón para crear una cuenta. Los vándalos que conducen no suelen ser calcetines. Y no pensé que esto se proponía como una cura para los calcetines, solo un vandalismo que puede ser bastante difícil de detectar. Estoy bien para que el límite base se eleve a mil transclusiones o algo así, pero SEMI es un bloqueo antivandálico muy efectivo. Además, la "enciclopedia que cualquiera puede editar" no se aplica aquí. El espacio de la plantilla es el mantenimiento y el marco de la enciclopedia, no el contenido. L3X1 (escritura distænt) 20:19, 21 de diciembre de 2017 (UTC)
- Comenta Primefac , ¿no sería más fácil implementar una restricción técnica como ACTRIAL en lugar de semi-proteger cada nueva plantilla? TonyBallioni ( charla ) 19:08, 21 de diciembre de 2017 (UTC)
- TonyBallioni , no me preocupa demasiado la creación de plantillas, me preocupa el vandalismo a las plantillas. El vandalismo a Template: Redirect-multi se realizó casi dos años después de que se creó la página. Primefac ( charla ) 19:24, 21 de diciembre de 2017 (UTC)
- Correcto, pero lo que estoy diciendo es que puede haber una manera de simplemente prohibir cualquier edición de plantillas a usuarios que no sean de AC en en.wiki sin tener que protegerlos manualmente, lo que sería ideal. TonyBallioni ( charla ) 19:26, 21 de diciembre de 2017 (UTC)
- TonyBallioni , no me preocupa demasiado la creación de plantillas, me preocupa el vandalismo a las plantillas. El vandalismo a Template: Redirect-multi se realizó casi dos años después de que se creó la página. Primefac ( charla ) 19:24, 21 de diciembre de 2017 (UTC)
- Oponerse básicamente por esto . Esta propuesta está bien, en teoría, para plantillas de larga data, prominentes, ampliamente utilizadas y transcluidas, generalmente plantillas de mantenimiento. Sin embargo, hay un notable mantenimiento de plantillas menos comunes por parte de usuarios nuevos y no registrados, incluidos aquellos con docenas de transclusiones. Encuentro que es especialmente notable en las plantillas deportivas, pero en varios otros temas: política, medios, software, todo tipo en realidad. Muchas de estas plantillas son mantenidas casi exclusivamente por usuarios no registrados. Varios cientos de transclusiones serían mi piso. En cambio, preferiría que el sistema actual de almacenamiento en caché y purga se mejore para reducir la longevidad del vandalismo. Además, los calcetines autoconfirmados son increíblemente fáciles de conseguir. - zzuuzz (charla) 19:12, 21 de diciembre de 2017 (UTC)
- Veo ese problema. Sin embargo, no veo por qué tiene que haber varios cientos de transclusiones. La mayoría de ellos tienen menos de 10 transclusiones. Galobtter ( pingó mió ) 03:58, 22 de diciembre de 2017 (UTC)
- Pero muchos tienen más de diez transclusiones. Es una figura basada en la experiencia. Tome algunos ejemplos aleatorios y oscuros editados recientemente por usuarios no registrados: Plantilla: Philip K. Dick - 184 transclusiones; Plantilla: Syracuse TV - 37 transclusiones; Plantilla: Miss Internacional - 64 transclusiones; Plantilla: Criptomonedas - 109 transclusiones; Plantilla: Pixar - 110 transclusiones; Plantilla: transclusiones de Flash 99. Hay muchas cosas así. - zzuuzz (charla) 07:22, 22 de diciembre de 2017 (UTC)
- Veo ese problema. Sin embargo, no veo por qué tiene que haber varios cientos de transclusiones. La mayoría de ellos tienen menos de 10 transclusiones. Galobtter ( pingó mió ) 03:58, 22 de diciembre de 2017 (UTC)
- Oponerse a Wikipedia es la enciclopedia que cualquiera puede editar, pero solo hay 159 editores con el derecho de editor de plantillas. Yo mismo no tengo este derecho y me molestaría ser considerado un vándalo sospechoso por defecto. Tenemos demasiado bloqueo progresivo de Wikipedia que tiende a acabar con el proyecto. Si se hubiera permitido que tal paranoia prevaleciera en los primeros días, Wikipedia nunca habría tenido éxito. Andrew D. ( charla ) 19:51, 21 de diciembre de 2017 (UTC)
- @ Andrew Davidson : Esta propuesta es semiproteger las plantillas, no protegerlas con plantillas. Solo pensé en aclarar eso.— CYBER POWER ( Feliz Navidad ) 20:09, 21 de diciembre de 2017 (UTC)
- Oponerse al argumento de zzuuzz es convincente. Jo-Jo Eumerus ( charla , contribuciones ) 20:01, 21 de diciembre de 2017 (UTC)
- Una especie de oposición, una especie de apoyo. 10 transclusiones es un límite demasiado bajo y el diablo está en los detalles. Tal vez más de 100 o más de 1000 y estaría bien con esto. Pero creo que un mejor enfoque podría ser simplemente identificar plantillas que no necesitan ser editadas regularmente y semiprotejarlas (por ejemplo, plantillas de mantenimiento semiprotegidas, infoboxes, etc.). Pero no veo la necesidad de semiproteger plantillas como navboxes, por ejemplo. Headbomb { t · c · p · b } 21:13, 21 de diciembre de 2017 (UTC)
- comentar ¿sería mejor, quizás, utilizar PC1? Me parece que es una forma útil de permitir que los usuarios de ip y los nuevos registrados realicen ediciones productivas, sin que se activen inmediatamente. (esto puede, sin embargo, requerir cambios técnicos. - Aunva6 talk - contribuciones 22:32, 21 de diciembre de 2017 (UTC)
- Admite semiprotección, pero SOLO para plantillas con más de 250 transclusiones. Los vándalos se sentirán atraídos por esas plantillas que se utilizan mucho para causar caos, por lo que lo más sencillo es semiproteger solo aquellas plantillas que se utilizan en muchos artículos a la vez. Como de costumbre, me opongo a CRASHlock por motivos ideológicos, sin mencionar que solo un idiota querría tantas páginas CRASHlock a la vez. - Jeremy v ^ _ ^ v ¡Bori! 22:57, 21 de diciembre de 2017 (UTC)
- Debe haber alguna forma vaga de averiguar si algo es una plantilla de mantenimiento o contenido. ¿Quizás hacer plantillas que tomen parámetros semi-protegidos? Algún tipo de solución de más de 10 transclusiones y eso. Pero también tendría que estar diseñado para prevenir abusos. Galobtter ( pingó mió ) 03:58, 22 de diciembre de 2017 (UTC)
- Oponerse . Aparte de los puntos de zzuuzz, aumentaría enormemente la carga de trabajo en WP: editores de plantillas (y administradores que responden a solicitudes que los TE también pueden hacer). Sí, las personas que no son ET podrían responder a solicitudes de edición de plantillas en plantillas que solo están semiprotegidas, pero la mayoría de ellas no lo saben, y probablemente no sería obvio cuál era el nivel de protección cuando se trataba de una solicitud en particular. . Creo que una propuesta más razonable sería semiproteger las plantillas con un número X de transclusiones. 100? 250? 1000? Soy bastante agnóstico al respecto. Una buena cosa sería encontrar la plantilla específica de deportes que se usa en la mayor cantidad de páginas que no sea un cuadro de información (no queremos que los anones agreguen o eliminen parámetros de un cuadro de información, porque esas plantillas son un WP masivo : DRAMA factory como es) y no un navobox (porque tenemos reglas sobre ellos, y los anons en su mayoría no los habrán leído). Es probable que existan plantillas de fútbol (soccer) relacionadas con la lista del equipo, uniformes ("kit"), clasificación de la liga, etc., que se usan en cientos de artículos al menos, posiblemente más de 1000, a los que anónimos con algo de experiencia podrían contribuir de manera significativa. Podría darnos una idea de en qué número deberíamos estar pensando. De todos modos, me gustaría ver la semiprotección automática en plantillas de uso elevado como un método antivandálico, y también como un medio para reducir la cantidad de plantillas que tienen protección de editor de plantillas para las que la semiprotección en realidad sería Ser suficiente. Eso no solo desperdiciará menos tiempo de TE, sino que también nos permitirá desarrollar más plantillas de forma anónima y no anónima. - SMcCandlish ☏ ¢ > ʌ ⱷ҅ ᴥ ⱷ ʌ < 05:07, 22 de diciembre de 2017 (UTC)
- Oponerse . Excelentes argumentos de zzuuzz. Leí el enlace de cambios recientes y, sorprendentemente, pocas de las diferencias enumeradas fueron vandalismo. Es posible que deseemos proteger las plantillas de mantenimiento muy utilizadas. Quizás 5000 transclusiones sería un buen piso para esto (por lo que he visto en el informe de plantillas más transcluidas ). Enterprisey ( ¡habla! ) 05:16, 22 de diciembre de 2017 (UTC)
- Soporte El vandalismo en la plantilla está afectando a varias páginas al mismo tiempo. Cualquier usuario de IP puede proponer cualquier cambio significativo a través de una solicitud de edición que normalmente no dura 24 horas sin obtener respuesta. - Ammarpad ( charla ) 09:15, 22 de diciembre de 2017 (UTC)
- Según datos recientes, esto afectaría alrededor de 1.500 ediciones cada semana. Creo que la mayoría ni siquiera se molestaría en hacer solicitudes, pero si incluso una proporción lo hiciera, esperaría que eso aumentara. - zzuuzz (charla) 10:53, 22 de diciembre de 2017 (UTC)
- Apoyaría una propuesta para usar un bot para dar a todas las plantillas con más de 10 transclusiones semiprotección, o protección de cambios pendientes si es posible; y eliminar la semiprotección si las plantillas, después de haber sido protegidas por el bot, tienen su número de transclusiones reducido por debajo de 10. La semiprotección automática de todas las plantillas es definitivamente excesiva (hacer que un bot encuentre la cantidad de transclusiones es definitivamente posible), y 5000 como mínimo para semi es definitivamente demasiado alto (yo diría que incluso 500 funcionarían para la protección de la plantilla ). Tenga en cuenta que ninguno de estos aumentaría la carga de trabajo de los editores de plantillas , ya que solo son necesarios para editar plantillas y módulos protegidos por plantillas. El bot también podría evitar la protección de plantillas que constan únicamente de cuadros de navegación o barras laterales, ya que se supone que se trasladan a muchas páginas por diseño y son relativamente fáciles de editar. Jc86035 ( conversación ) 11:38, 22 de diciembre de 2017 (UTC)
- Comentario de OP Bien, algunas cosas que he visto siguen apareciendo:
- Primero, todas las plantillas con más de 1000 transclusiones ya están semi (y 5k + TE). Esta propuesta habla de aquellos con transclusiones 0-999 potencialmente vandalizados.
- En segundo lugar, la propuesta es de semiprotección , lo que no aumentaría los trabajos del editor de plantillas de ninguna manera, forma o forma. Por supuesto, serían bienvenidos a patrullar las solicitudes de edición para problemas de espacio de plantilla, pero no es obligatorio.
- En tercer lugar (saliendo de la nota anterior), los TEs no están precisamente golpeados bajo el peso de la responsabilidad. Recibimos quizás tres solicitudes de TPER a la semana.
- Solo sentí que debería aclarar esas cosas en el futuro. Admitiré que las direcciones IP no son del todo malas con sus cambios, especialmente en las plantillas deportivas, pero ese tipo de plantillas que se actualizan con frecuencia son (en su mayor parte) plantillas de una sola temporada que rara vez se usan en más de 10 páginas (lo que significa que la opción 10+ de semiprot no los afectaría). Si Cyberpower dice que puede hacer un bot para hacerlo, entonces no implicaría ningún cambio de software. Primefac ( charla ) 13:22, 22 de diciembre de 2017 (UTC)
- Y por lo que vale, no me importa particularmente si nos decidimos por 10+ o 250+ o 500+, pero creo que debería haber algún umbral para las plantillas de semiprotección. Primefac ( charla ) 13:24, 22 de diciembre de 2017 (UTC)
- Entonces ... si (asumiendo que podemos) ejecutar los números, mirando la frecuencia de ediciones y el número de transclusiones, ¿cómo se ve ese gráfico? ¿Existe algún umbral basado en la evidencia por debajo del cual la mayoría de los editores de IP puedan avanzar felizmente, mientras que el resto de nosotros podemos evitar que se trasladen la polla y las pelotas en unos pocos cientos de páginas cada pocas semanas? G M G talk 13:44, 22 de diciembre de 2017 (UTC)
- Y por lo que vale, no me importa particularmente si nos decidimos por 10+ o 250+ o 500+, pero creo que debería haber algún umbral para las plantillas de semiprotección. Primefac ( charla ) 13:24, 22 de diciembre de 2017 (UTC)
- Oponerse , el nivel de protección actual funciona generalmente bien y el nivel de vandalismo en las plantillas no es muy alto. La franqueza ("cualquiera puede editar") es más importante que restringir el vandalismo a las cuentas durmientes. - Kusma ( t · c ) 18:17, 22 de diciembre de 2017 (UTC)
- Oponerse a la protección de las mantas. El argumento de zzuuzz es convincente y esta es la enciclopedia libre que cualquiera puede editar. En un cierto número de transclusiones, la compensación apunta en la dirección de la protección. Entonces apoyaría una regla de transclusiones x +. Malinaccier ( charla ) 18:28, 22 de diciembre de 2017 (UTC)
- Oponerse , hay plantillas como competiciones deportivas, alineaciones de equipos deportivos, lista de estaciones, etc., donde las contribuciones de IP son principalmente constructivas y útiles. Podría apoyar la protección x +, aunque 10 inclusiones parecen una barra baja para mí (una alineación de un equipo de fútbol tiene al menos 23 + el equipo + el entrenador), pensaría más en cincuenta más o menos .-- Ymblanter ( hablar ) 00 : 00, 25 de diciembre de 2017 (UTC)
Oponerse Esta es la enciclopedia que cualquiera podría editar. Funcionalmente , semi-proteger todo sería genial, pero no es lo que hacemos y es fundamentalmente en contra de nuestras ideas. No hagas esta acción instintiva. Sea inteligente y juzgue caso por caso. ! dave 08:17, 28 de diciembre de 2017 (UTC)trasladado a soporte- Oponerse . Hay muchas plantillas que serían perfectamente legítimas para que los editores más nuevos las editen, especialmente las cajas de navegación y similares. Apoyaría la semi-protección de todo con más de 100 transclusiones. Probablemente deberíamos crear un filtro de edición que registre las ediciones más recientes del editor en el espacio de nombres de la plantilla, como un aparte. ~ Rob 13 Talk 08:24, 28 de diciembre de 2017 (UTC)
- @ BU Rob13 : Si utiliza el formulario de nuevos filtros en RC / WL / RCL (consulte las preferencias de la versión beta), todas estas ediciones no son de EC para el espacio de la plantilla . - Izno ( charla ) 13:39, 28 de diciembre de 2017 (UTC)
- Compatibilidad con plantillas utilizadas más de 100/200 veces, pero generalmente se oponen . Doc James ( charla · contribuciones · correo electrónico ) 05:59, 30 de diciembre de 2017 (UTC)
- Oponerse por completo por mi respuesta a BU Rob13. La mayoría de los cambios realizados en el espacio de la plantilla por usuarios que no pertenecen a EC son buenos cambios; actualizaciones de rutina a navboxes aparentemente la mayoría de tales cambios. - Izno ( charla ) 06:32, 1 de enero de 2018 (UTC)
- Oponerse a las transclusiones de conteo no es tan útil en el vandalismo de plantillas, realmente te preocupas por las visitas a la página. Si una plantilla se transcluye 30 veces, pero una de esas páginas es Obama, es una plantilla muy vista y debe protegerse. Pero si se utiliza una plantilla de código auxiliar en mil páginas que apenas se leen, protegerla es de poca utilidad. Además de eso, proteger un espacio de nombres completo es un camino extremadamente peligroso para pasar por la OMI. Siempre deberíamos abrir por defecto. Legoktm ( charla ) 07:11, 2 de enero de 2018 (UTC)
- La semiprotección de soporte no es un obstáculo insuperable. El beneficio de esta propuesta supera las preocupaciones, en mi opinión. James ( charla / contribuciones ) 14:43, 2 de enero de 2018 (UTC)
- Soporte con un umbral razonable de transclusiones (¿200?). Peter coxhead ( charla ) 16:01, 2 de enero de 2018 (UTC)
- Las plantillas de soporte que se utilizan en más de 200 páginas deben estar semiprotegidas permanentemente. Sin embargo, no parece razonable semiproteger todas las plantillas. He visto ediciones constructivas realizadas por editores de IP en plantillas. Protección confirmada ampliada para todas las plantillas que se utilizan para advertir a los usuarios sobre sus ediciones. Pkbwcgs ( charla ) 16:49, 2 de enero de 2018 (UTC)
- Soporte siempre y cuando a) haya un umbral de transclusión, b) el bot elimine la protección cuando una página cae por debajo del umbral de transclusión, yc) haya un mecanismo para solicitar que una plantilla esté desprotegida (y una bandera que el bot obedecerá ). - Ahecht (
PÁGINA DE HABLAR) 22:28, 2 de enero de 2018 (UTC) - Oponerse per zzuuzz, Kusma et al. Es mejor aplicar la protección necesaria manualmente de forma individual. Al final del día, es poco probable que los nuevos vándalos conozcan el espacio de la plantilla de todos modos, y aquellos que quieran interrumpir deliberadamente el proyecto no tendrían problemas para esperar hasta que se confirmen automáticamente. Optimist on the run ( charla ) 11:22, 4 de enero de 2018 (UTC)
- Oponerse, según zzuuzz et al., No todas las IP son vándalos y el otro punto es "Somos una enciclopedia que cualquiera puede editar" ... estaríamos frustrando el propósito del objeto si bloqueáramos todas las plantillas, mientras que en teoría Estoy de acuerdo con esta propuesta a menos que prohibamos toda la edición de IP (¡lo cual suena genial!), Entonces creo que es mejor quedarse con la semi protección aquí y allá y el bloqueo aquí y allá. - Davey 2010 Talk 16:47, 5 de enero de 2018 (UTC)
- Soporte , no hay una opinión particular sobre el mejor número para el corte. - SarekOfVulcan (charla) 19:02, 8 de enero de 2018 (UTC)
- Oponerse por motivos ideológicos. Esto es
la enciclopedia gratuita que cualquiera puede editar.
La protección de tantas plantillas va en contra de los principios de Wikipedia . AdA & D 19:28, 8 de enero de 2018 (UTC)- Tengo malas noticias para ti; comenzaremos con cómo las direcciones IP no pueden crear páginas y se oscurecen progresivamente a partir de ahí ... - El ping de Bushranger One solo 07:10, 13 de enero de 2018 (UTC)
- Soporte . Las plantillas son un gran agujero en nuestra protección antivandálica; una edición puede mostrar una imagen ofensiva, un mensaje que infringe WP: BLP o incluso un enlace a malware en docenas o incluso cientos de páginas. Lo siento por nuestros editores de IP, pero ese caballo dejó el granero hace años (y ni siquiera sería un problema en absoluto si la WMF escuchara a sus editores con respecto a SITE, pero eso es una olla de surstromming completamente diferente) . Esto es algo que debe hacerse, porque la alternativa es esperar hasta que nos veamos obligados a hacerlo, en términos que probablemente no lleguemos a dictar. - Solo ping de Bushranger One a las 07:10, 13 de enero de 2018 (UTC)
- Soporte . WP: Las direcciones IP no son personas . Las direcciones IP son gratuitas para realizar ediciones básicas, pero esta es una situación en la que el riesgo de daño supera el beneficio de la edición en una plantilla. Mi segunda opción limitaría la protección a las plantillas que se utilizan en una docena o más de artículos. Dennis Brown - 2 ¢ 18:56, 13 de enero de 2018 (UTC)
- Admite plantillas de semiprotección con ~ 250 + transclusiones (o algún otro número razonable determinado por consenso). Tony Tan · charla 03:59, 17 de enero de 2018 (UTC)
- Soporte Esta se está convirtiendo en una forma cada vez más fácil de hacer una pequeña edición y hacer mucho daño. Hay partes de Wikipedia en las que simplemente no confiamos con los editores que no han demostrado capacidad para editar. Estos son importantes para el funcionamiento interno de Wikipedia. Las plantillas, creo, caen bajo esa distinción. Esto no se detendrá hasta que estén protegidos contra el vandalismo. - Tarage ( conversación ) 22:22, 22 de enero de 2018 (UTC)
- El vandalismo de las plantillas de soporte es un problema cada vez mayor y, a medida que se protegen las plantillas que se trasladan con mayor frecuencia, las plantillas más oscuras, a menudo en páginas con menos tráfico y / o observadores que las cuidan, serán las que se dirijan con mayor frecuencia. El vandalismo de plantillas es más difícil de arreglar para la mayoría de los editores que el vandalismo de artículos regulares y, como resultado, hace más daño a Wikipedia. En mi humilde opinión, el daño causado al no proteger el espacio de nombres de la plantilla de esta manera supera en gran medida los inconvenientes causados por evitar que los usuarios de IP editen lo que, para ser justos, es un área bastante especializada y de nicho del proyecto. Yunshui 雲水23:18, 22 de enero de 2018 (UTC)
- Soporte El vandalismo de la plantilla es un problema real, y es fácil para un vándalo tropezar con una plantilla; no necesita comprender el software. Ya restringimos el acceso a muchas plantillas a los editores de plantillas. Hawkeye7 (discutir) 00:11, 23 de enero de 2018 (UTC)
- Oposición débil Realmente necesitamos algo para ayudar con esto, la cantidad de daño que se puede hacer es desconcertante, y generalmente nos lo informa una persona al azar en IRC, después de que el spammer haya obtenido miles de visitas. No creo que debamos limitar la edición de plantillas debido a nuestras propias deficiencias técnicas. Sé que hay un plan en proceso para eliminar la necesidad de purgar, pero una "purga recursiva" es una necesidad en este momento. Drewmutt ( ^ ᴥ ^ ) charla 00:53, 23 de enero de 2018 (UTC)
- Soporte : mismas sugerencias que Ahecht . Por supuesto, las páginas de discusión de plantilla deben excluirse. - Hei Liebrecht 16:02, 25 de enero de 2018 (UTC)
- Apoyo débil No me gusta esta propuesta, porque restringe uno de nuestros principios, pero el vandalismo reciente me ha hecho cambiar de opinión. ! dave 17:44, 27 de enero de 2018 (UTC)
- Oponerse a : WP: Los IP también son humanos . Además de los fundamentos ideológicos sobre los que se fundó WikiMedia, esta propuesta esencialmente agrega impedimentos significativos al desarrollo de plantillas por parte de usuarios de IP anónimos que ya están demasiado censurados en masa . Aunque esta clase de usuarios comete una cantidad significativa de vandalismo, también lo es una cantidad significativa de contenido útil generado por dichos usuarios. La progresión natural es extender esto para aplicar protecciones masivas similares al espacio del Módulo. Tenga en cuenta que esta propuesta penaliza a una gran clase de editores por las acciones de unos pocos (aunque persistentes) en esta clase. Entiendo que existe un equilibrio entre el trabajo necesario para vigilar el vandalismo y el valor generado por la clase de usuarios sancionados, pero creo que esta propuesta va demasiado lejos. Escuchamos a los usuarios registrados sobre los crecientes problemas de vandalismo, pero recordemos que también están los crecientes problemas de censura a un grupo de usuarios que ya tienen dificultades para hacer oír sus problemas. Recuerde que este tipo de propuesta no solo bloquea a los vándalos, sino que también bloquea a los usuarios de IP anónimos (que son una gran cantidad de globos oculares) para que no reviertan el vandalismo, por lo que de hecho esto podría aumentar el daño causado por vándalos más decididos. 50.53.21.2 ( conversación ) 05:17, 28 de enero de 2018 (UTC)
- Oponerse : las plantillas deben estar semiprotejadas individualmente. - NaBUru38 ( conversación ) 19:39, 31 de enero de 2018 (UTC)
- Soporte En cualquier número de transclusión se llega por consenso. Ron h jones (Discusión) 17:59, 3 de febrero de 2018 (UTC)
Discusión (semiproteger permanentemente el espacio de la plantilla)
- Si se adopta la propuesta, entonces el punto de corte del recuento de transclusiones debería estar en algún lugar por encima de 200. La gran mayoría de las plantillas son cajas de navegación: no son objeto de actos de vandalismo con frecuencia y requieren bastante mantenimiento que los anónimos generalmente pueden y dispuesto a ayudar. - Uanfala (conversación) 15:46, 24 de diciembre de 2017 (UTC)
- No he observado mucho el historial de edición de plantillas. Pero el comentario anterior de Uanfala tiene sentido. Además, al hacer esto, eliminaremos una cosa más de "cualquiera puede editar". Sí, cualquiera puede editar, pero necesitas una cuenta. Además, debe esperar de 4 a 5 días y realizar 11 ediciones antes de poder editar.
Además, si es un vándalo que va a destrozar a través de plantillas, creo que ya está familiarizado con los conceptos de calcetines y durmientes. Así que no veo mucho sentido en implementar estas propuestas. ping de cortesía a Uanfala para informarles que su comentario fue movido. - usernamekiran (conversación) 23:44, 24 de diciembre de 2017 (UTC)
- En general, los vándalos optarán primero por el fruto de las plantillas desprotegidas. (Tenga en cuenta que no soy compatible con la semiprotección de todas las plantillas, solo aquellas con más de 250 transclusiones). Se necesita tiempo y ediciones para crear un autocon-buster, y en general, la mayoría de los vándalos que crearían autocon-busters tienen objetivos muy específicos en mente, en lugar de simplemente causar un caos generalizado . Grabar un autocon-buster en plantillas es una MUY buena manera de sacar el resto de su cajón de calcetines o bloquear las IP de su servicio de anonimización, ya que, como mencioné en el PC2 RfC, usar un autocon-buster virtualmente garantiza la atención de CheckUser. No existe tal cosa como un autocon-buster drive-by. - Jeremy v ^ _ ^ v ¡Bori! 23:27, 26 de diciembre de 2017 (UTC)
- El subespacio de plantillas no solo contiene plantillas, sino también sus páginas de discusión. Los nuevos usuarios deberían poder pedir ayuda en las páginas de discusión de las plantillas, por lo que las páginas de discusión no deben estar semiprotejadas. ChristianKl ❪ ✉ ❫ 22:57, 31 de diciembre de 2017 (UTC)
- Hasta ahora, dos ideas parecen estar flotando: una, que un bot protege cualquier plantilla con más de 10 transclusiones (usos) o un cambio de configuración en todo el sitio para el espacio de nombres de la plantilla . En ninguno de los casos se verían afectadas las páginas de discusión. :) Killiondude ( charla ) 03:31, 1 de enero de 2018 (UTC)
¿Al menos podemos tener semiprotección para más de 100 transclusiones? Otro incidente ocurrió hoy que muestra por qué realmente se necesita. {{ Sidebar person }} se incluye en 564 páginas, incluido Donald Trump. Sin embargo, estaba completamente desprotegido y alguien lo destrozó, de modo que un enorme "joder donald trump" se mostró durante al menos 40 minutos (probablemente más) al menos 2 horas (según una publicación de Reddit), 2 horas después de que se revirtiera el vandalismo. (solo para usuarios desconectados, porque aparentemente obtienen una versión en caché de la página, por lo que los editores habituales no la vieron) Estoy pensando que después de esa semiprotección automática, a discreción del administrador, plantillas de mantenimiento que no deberían ser Mucho cambiado puede ser de forma preventiva plantilla / semiprotegido. Galobtter ( pingó mió ) 11:25, 1 de enero de 2018 (UTC) Me pregunto si hay una forma más inteligente de hacerlo. Las plantillas que se transfieren a otras plantillas (como esa) deben protegerse con un recuento menor. Estoy seguro de que hay formas razonables para que las plantillas de estadísticas deportivas, etc., no estén protegidas, mientras que otras como estas sí. Galobtter ( pingó mió ) 11:52, 1 de enero de 2018 (UTC)
- No capté este vandalismo en particular, sin embargo, quiero subrayar el hecho de que ahora que esta plantilla está protegida, hemos restringido efectivamente la cantidad de editores que pueden responder (es decir, revertir) el vandalismo de esta plantilla (por parte de vándalos más decididos). ). De hecho, esto puede causar más daño debido al vandalismo, ya que el vandalismo puede durar más tiempo a pesar de que los usuarios de IP anónimos ven el problema pero no pueden hacer nada al respecto directamente. 50.53.21.2 ( conversación ) 05:51, 28 de enero de 2018 (UTC)
- Este problema de subtransclusión es, por supuesto, uno importante que no se ha abordado anteriormente. Lo que el vandalismo actual muestra, una vez más, es que se trata de plantillas con no solo decenas o cientos de transclusiones, sino varios cientos de transclusiones. Las plantillas que generaron este hilo fueron alrededor de 1,000 transclusiones. Pero también el problema real no es el vandalismo sino el almacenamiento en caché y no hay medios efectivos para romper los cachés. - zzuuzz (charla) 12:03, 1 de enero de 2018 (UTC)
- Otra herramienta podría ser una capacidad de administrador para purgar masivamente la caché, tal vez la caché generada en un cierto período de tiempo (cuando la plantilla fue objeto de vandalismo) vinculada a una determinada plantilla. Galobtter ( pingó mió ) 12:15, 1 de enero de 2018 (UTC)
- ¿Alguien ha confirmado o escuchado si eso se vio en alguna otra página o simplemente le pasó a Donald Trump? Emir de Wikipedia ( charla ) 16:49, 1 de enero de 2018 (UTC)
- Sí otros [5] [6] . - zzuuzz (charla) 16:54, 1 de enero de 2018 (UTC)
- Wikipedia: Purge # forcerecursivelinkupdate es interesante Galobtter ( pingó mió ) 16:56, 1 de enero de 2018 (UTC)
- Aparentemente puede forzar la actualización de la caché de todas las páginas transcluidas. Galobtter ( pingó mió ) 16:58, 1 de enero de 2018 (UTC)
- ¿Alguien ha confirmado o escuchado si eso se vio en alguna otra página o simplemente le pasó a Donald Trump? Emir de Wikipedia ( charla ) 16:49, 1 de enero de 2018 (UTC)
- Otra herramienta podría ser una capacidad de administrador para purgar masivamente la caché, tal vez la caché generada en un cierto período de tiempo (cuando la plantilla fue objeto de vandalismo) vinculada a una determinada plantilla. Galobtter ( pingó mió ) 12:15, 1 de enero de 2018 (UTC)
- Otra plantilla de 900 páginas fue alcanzada esta mañana. Primefac ( charla ) 16:38, 10 de enero de 2018 (UTC)
- Plantilla de 200 páginas que recibió el impacto, así como plantillas de 110 y 31 páginas . Como nota menor, esto fue después de que semiprotejé todas las plantillas con más de 350 transclusiones, por lo que, aunque todavía están siendo objeto de vandalismo, las plantillas tienen un impacto menor ya que eligen (para citar a Bushranger) la "fruta más baja". . Primefac ( charla ) 14:34, 14 de enero de 2018 (UTC)
Si queremos reducir el impacto del vandalismo, sería mucho mejor permitir que tantos usuarios como sea posible respondan al vandalismo en lugar de restringir tanto el vandalismo como cualquier respuesta al vandalismo a grupos de usuarios cada vez más pequeños. Los vándalos, por definición, son un grupo pequeño de usuarios y, como tales, siempre pueden ser frustrados por una población más grande. Agregar restricciones solo significa que los vándalos tendrán que estar más decididos a eludir las restricciones. Como tal, las restricciones no son una práctica sostenible. Actualmente, las herramientas anti-vandalismo son difíciles, si no imposibles, de acceder y utilizar por usuarios de IP anónimos que son, de hecho, el conjunto más grande de usuarios y editores dentro de los proyectos de WikiMedia. 50.53.21.2 ( conversación ) 06:08, 28 de enero de 2018 (UTC)
- Comentario : por alguna razón mística, nadie ha mencionado la guía de Wikipedia: Plantillas de alto riesgo . - NaBUru38 ( charla ) 20:02, 31 de enero de 2018 (UTC)
- Sigo siendo de la opinión de que todo en este espacio de nombres debería ser protección de cambios pendientes / cambios diferidos / como queramos llamarlo, para ediciones no realizadas por sysops. Tener 2 personas revisando los cambios de código de los demás no es más de lo normal en CUALQUIER espacio donde el código se implementa para tantas personas al mismo tiempo y me parece perfectamente razonable. No estoy seguro de por qué nos estamos molestando con la semiprotección, simplemente se siente como una portería en movimiento para los vándalos, que simplemente pasará al siguiente nivel de menor resistencia. - Th e DJ ( hablar • contribuciones ) 14:58 7 de febrero 2018 (UTC)
- @ TheDJ : Creo que también queremos excluir bots y editores de plantillas. Los primeros, ya que están estrictamente controlados por las aprobaciones de tareas, y los últimos, ya que están seleccionados específicamente para esta función y muchos son más expertos en este mantenimiento que algunos operadores de sistema. - xaosflux Talk 15:32, 7 de febrero de 2018 (UTC)
- @ TheDJ y Xaosflux : esto necesitaría cambios de software, ya que la transclusión actualmente recoge la última versión incluso si no se ha revisado. Actualmente, la lista de villanos de telenovelas tiene cambios no revisados y se incluye en Usuario: John de Reading / X3 . Al ver ambos sin cerrar sesión, veo la versión anterior del artículo real, pero la última versión en mi caja de arena. - John of Reading ( charla ) 16:06, 7 de febrero de 2018 (UTC)
Haciendo un número
Parece que alrededor de la mitad de los votos "opuestos" se oponen al semiprogatorio "general", que yo entiendo. Esa mitad también mencionó que una opción alternativa era una opción "X + transclusiones". Teniendo en cuenta que el% de los votos que estarían dispuestos a aceptar eso es más que el "duro opositor", creo que es hora de desarrollar un número. Los números que se arrojaron más fueron 10+ , 100+ y 250+ . Entonces, a pesar de mi preocupación personal de que nunca nos pondremos de acuerdo en nada , me gustaría ver si podemos intentarlo. Primefac ( charla ) 02:21, 4 de enero de 2018 (UTC)
Más de 100 : es una barra lo suficientemente alta como para que las plantillas de tipo deportivo que se actualizan con frecuencia con las IP útiles no se vean afectadas, pero evita que las plantillas "más grandes" causen más daño del necesario (y <100 páginas es pan comido para que alguien con AWB haga una edición nula rápidamente). Primefac ( charla ) 02:21, 4 de enero de 2018 (UTC)- 250+ según los comentarios a continuación. Sigue siendo una barra baja para ediciones AWB / nulas. Primefac ( charla ) 13:56, 8 de enero de 2018 (UTC)
- 250+ ; Dejé mis razones claras arriba. - Jeremy v ^ _ ^ v ¡Bori! 02:27, 4 de enero de 2018 (UTC)
- Más de 250 o más de 10 páginas semiprotegidas . (No estoy seguro de que esta sugerencia sea factible) Plantillas como Plantilla: la caja de navegación de baloncesto masculino de Duke Blue Devils debería poder permanecer desprotegida. Las plantillas incluidas en páginas de alto perfil deben tener un umbral más bajo. power ~ enwiki ( π , ν ) 11:56, 4 de enero de 2018 (UTC)
- Espera, ¿estamos hablando de semiprotección o de protección por cambios pendientes? Podría admitir cambios pendientes para todo el espacio de nombres. power ~ enwiki ( π , ν ) 12:17, 4 de enero de 2018 (UTC)
- @ Power ~ enwiki : No creo que el software admita cambios pendientes en las plantillas, ya que el software siempre incluirá la última versión. Sin embargo, no puedo encontrar dónde leo eso. - John of Reading ( charla ) 07:23, 5 de enero de 2018 (UTC)
- Sin mencionar que eso sería una gran tensión para la colmena de idiotas que es CRASH. Como dije anteriormente, solo los tontos querrían tantas páginas bloqueadas por CRASH. - Jeremy v ^ _ ^ v ¡Bori! 20:36, 5 de enero de 2018 (UTC)
- Espera, ¿estamos hablando de semiprotección o de protección por cambios pendientes? Podría admitir cambios pendientes para todo el espacio de nombres. power ~ enwiki ( π , ν ) 12:17, 4 de enero de 2018 (UTC)
- Sin números, por favor . Si se nos ocurre una regla que hace referencia a un número en particular, me temo que esto tendrá el efecto de desalentar el ejercicio del sentido común. Si hay algún mensaje para llevar a casa de la discusión anterior, es que las circunstancias varían entre las plantillas y que se debe ejercer algún criterio básico. Si es poco probable que se edite una plantilla, por ejemplo, si es simplemente un contenedor para un módulo o si produce un código muy simple que es poco probable que se cambie, entonces puede estar protegida incluso si tiene un número bajo de transclusiones ( digamos, 30). Por otro lado, si se trata de una plantilla grande que probablemente necesite algún tipo de mantenimiento regular (como una caja de navegación), por lo general no tiene sentido protegerla, incluso si tiene miles de transclusiones. - Uanfala (conversación) 15:23, 11 de enero de 2018 (UTC)
- Todo el motivo de esta discusión se debe a la creciente frecuencia de vandalismo con respecto a las plantillas con cientos de transclusiones, ya que interrumpe enormemente los artículos en los que luego se transcluye la plantilla; de ahí los números. Semiprotección general de la plantilla: el espacio no es viable ni viable, por lo que el objetivo debería ser eliminar la fruta más tentadora y fácil para evitar este tipo de vandalismo. - Jeremy v ^ _ ^ v ¡Bori! 21:43, 11 de enero de 2018 (UTC)
- Mi deseo sería protegerlos a todos , ya que solo proteger "la fruta madura más tentadora" simplemente hará que la fruta de la siguiente rama aumente su valor de tentación. Pero si se debe establecer un número , 10+. - Solo ping de Bushranger One a las 07:10, 13 de enero de 2018 (UTC)
- Desafortunadamente, lo mismo ocurre con la semiprotección, no es difícil alcanzar el nivel de confirmación automática con ediciones triviales, incluso en una caja de arena ... - Paleo Neonate - 10:39, 13 de enero de 2018 (UTC)
- Sin embargo, el vandalismo de plantillas prácticamente siempre ocurre desde el vehículo. Configurar un autocon-buster lleva tiempo, y dado que el objetivo de estas cuentas es causar interrupciones para una risa rápida y luego seguir adelante, eso requiere más tiempo y dedicación de lo que están dispuestos a gastar. - Jeremy v ^ _ ^ v ¡Bori! 17:48, 13 de enero de 2018 (UTC)
- Desafortunadamente, también se necesita la misma determinación para que alguien que ve el vandalismo responda a él. Las protecciones generales con recuentos de transclusiones cada vez más bajos significan que menos personas pueden responder a un vandalismo más decidido. 50.53.21.2 ( conversación ) 06:19, 28 de enero de 2018 (UTC)
- La mayoría de los usuarios / lectores no registrados que ven el vandalismo de plantillas generalmente no lo reconocen como tal y miran el artículo solo para aparecer con las manos vacías, razón por la cual el vandalismo de plantillas es disruptivo hasta el punto en que la protección general de todas las plantillas que son transcluido en un número X de páginas es una opción mucho mejor que ver docenas o cientos de artículos todos vandalizados a la vez. - Jeremy v ^ _ ^ v ¡Bori! 06:55, 28 de enero de 2018 (UTC)
- Tengo curiosidad por saber cómo ha llegado a tal determinación. ¿Tiene alguna métrica convincente? También creo que necesitamos algo más que un recuento de translusión genérico como medida de impacto. Como plantilla de ejemplo : Sandbox other está actualmente semiprotegido con más de 3000 transclusiones, pero ni una sola de ellas está en el espacio del artículo . 50.53.21.2 ( conversación ) 08:07, 28 de enero de 2018 (UTC)
- La mayoría de los usuarios / lectores no registrados que ven el vandalismo de plantillas generalmente no lo reconocen como tal y miran el artículo solo para aparecer con las manos vacías, razón por la cual el vandalismo de plantillas es disruptivo hasta el punto en que la protección general de todas las plantillas que son transcluido en un número X de páginas es una opción mucho mejor que ver docenas o cientos de artículos todos vandalizados a la vez. - Jeremy v ^ _ ^ v ¡Bori! 06:55, 28 de enero de 2018 (UTC)
- Desafortunadamente, también se necesita la misma determinación para que alguien que ve el vandalismo responda a él. Las protecciones generales con recuentos de transclusiones cada vez más bajos significan que menos personas pueden responder a un vandalismo más decidido. 50.53.21.2 ( conversación ) 06:19, 28 de enero de 2018 (UTC)
- Sin embargo, el vandalismo de plantillas prácticamente siempre ocurre desde el vehículo. Configurar un autocon-buster lleva tiempo, y dado que el objetivo de estas cuentas es causar interrupciones para una risa rápida y luego seguir adelante, eso requiere más tiempo y dedicación de lo que están dispuestos a gastar. - Jeremy v ^ _ ^ v ¡Bori! 17:48, 13 de enero de 2018 (UTC)
- Desafortunadamente, lo mismo ocurre con la semiprotección, no es difícil alcanzar el nivel de confirmación automática con ediciones triviales, incluso en una caja de arena ... - Paleo Neonate - 10:39, 13 de enero de 2018 (UTC)
- 250+ es un número razonable. Tony Tan · charla 04:02, 17 de enero de 2018 (UTC)
- Estaría bien con 250+ , sí. Headbomb { t · c · p · b } 22:48, 17 de enero de 2018 (UTC)
- Actualizar . Las plantillas con más de 200 transclusiones parecen ahora semiprotegidas. - Uanfala (charla) 00:43, 31 de enero de 2018 (UTC)
Un bot para crear talones de artrópodos
Estoy interesado en agregar alrededor de 17,000 nuevos artículos de talón para especies de artrópodos. Estos se pueden agregar durante un período de varias semanas o unos meses con un bot. El contenido del artículo es significativamente mejor que el código auxiliar mínimo que se ve con frecuencia en estos y temas similares de Wikipedia.
En mi opinión, estos resguardos servirán para tres propósitos principales:
- Darán a los usuarios una idea del organismo, incluidas referencias y, si están disponibles, una foto o dos.
- Pondrán a disposición de los usuarios referencias impresas y en línea.
- Contendrán suficiente material para que sea conveniente para los editores expandir el artículo. Un editor casual puede dedicar mucho menos tiempo a expandir un artículo existente que a crear uno nuevo, porque se necesita tiempo para aprender y trabajar con las diversas plantillas y otros "estándares". Un artículo con referencias en línea hace que sea aún más probable que el artículo se expanda a un artículo de primera clase o mejor.
He solicitado y recibido comentarios positivos de los proyectos Arthropods y Tree of Life . He estado publicando manualmente nuevos artículos de resguardo generados para una variedad de artrópodos, principalmente insectos y arañas, durante las últimas semanas por recomendación y aliento de los miembros del proyecto y los editores interesados. He recibido comentarios positivos y la calidad del código auxiliar ha evolucionado y mejorado significativamente. Varios editores ya han ampliado varios de los stubs.
- User_talk: Edibobb # ¡Bienvenido!
- User_talk: Edibobb # Comments_on_your_stubs
- User_talk: Edibobb # Speciesbox
- Wikipedia_talk: WikiProject_Arthropods # Adding_Species_Stub_Articles
- Wikipedia_talk: WikiProject_Tree_of_Life # Adding_Species_Stub_Articles
Hoy solicité la aprobación para la operación del bot y me dirigieron a Village Pump para más discusión.
Detalles de la operación
El código fuente de VB está disponible en Usuario: Qbugbot / source .
Selección de especies
El ITIS tiene la mayoría de las especies de artrópodos establecidas desde hace mucho tiempo en su base de datos, aunque no tiene muchas de las especies más nuevas y es posible que no refleje la reorganización reciente de géneros y taxones superiores. Las especies en Bugguide generalmente reflejan las últimas investigaciones y se limitan principalmente a especies fotografiadas o recolectadas en América del Norte por sus usuarios. Al seleccionar las especies que aparecen tanto en ITIS como en Bugguide, terminamos con un conjunto de especies no controvertidas (desde un punto de vista taxonómico) que no son demasiado raras u oscuras.
- 35.000 especies de artrópodos están en la guía de insectos.
- 23.000 de estos están en ITIS (de un total de 250.000 especies de artrópodos en ITIS).
- 17.000 de estos no tienen ningún artículo de Wikipedia.
Creación de artículos
Los artículos se crean en los siguientes pasos:
- Se crea una plantilla de taxobox utilizando la ascendencia (taxonómica) del "error", seleccionando los rangos apropiados para el taxobox. Por ejemplo, la subfamilia debe incluirse excepto en Lepidoptera sin nombre común de subfamilia. Se incluye una imagen si está disponible. Se agregan sinónimos si aparecen en la base de datos ITIS. (Otros catálogos pueden tener un número ridículo de sinomimos).
- Se genera una introducción de texto, como " Andrena perarmata , la andrena bien armada , es una especie de abeja minera de la familia Andrenidae ", dando el nombre científico, nombres comunes (si los hay), rango taxonómico, el nombre común de un ancestro, y el nombre científico de la familia u orden.
- A esto le sigue, según esté disponible, el rango de distribución, el estado de conservación de la UICN, el número de Hodges, las notas taxonómicas del ITIS, imágenes adicionales y una lista de hijos taxonómicos (si los hubiera). Si hay demasiados niños, se incluye un enlace a una página de lista separada (creada posteriormente). Los datos de distribución provienen de ITIS, World Spider Catalog u Odonata Central.
- Las referencias pueden incluir citas en línea, referencias generales, lecturas adicionales y enlaces externos.
- Se agrega una plantilla de Wikimedia Commons si hay fotos, se agrega un Taxonbar si Wikidata tiene este error en la lista, se selecciona la categoría de Wikipedia apropiada y se selecciona la plantilla de código auxiliar adecuada para la página de discusión.
Carga de artículo
Los artículos se crean a pedido para su carga. Se cargará un artículo solo si no existe ningún artículo para ese título. Si existe alguno, se omitirá el artículo. No se modificará ningún artículo existente. Si el padre taxonómico de un artículo cargado no existe, se generará y cargará. Si se incluye una lista de más de 100 "niños" en el artículo, se dividirá como un artículo de lista independiente. Se crea una página de discusión con la plantilla de código auxiliar adecuada para cada artículo.
Verificación manual
Durante el período de prueba, cada artículo creado se verá en Wikipedia para verificar que existe, es el artículo correcto y la información es correcta. Posteriormente, el texto de todos los artículos del día se descargará y verificará de forma manual o automática. Al menos un artículo diario se verá manualmente en Wikipedia.
Artículos de muestra
Aquí hay una lista de algunos artículos de prueba aleatorios generados y publicados manualmente el 1 de febrero.
- Acmaeodera decipiens
- Acmaeodera hepburnii
- Agrilaxia flavimana
- Amara pseudobrunnea
- Antrodiaetus pugnax
- Apsectus hispidus
- Arhyssus
- Arhyssus scutatus
- Detritus de Bassareus
- Bembidion salebratum
- Blissus insularis
- Boopedon
- Boopedon auriventris
- Cannaphila insularis
- Chalepini
- Chrysobothrini
- Chrysobothris breviloba
- Chrysopilus velutinus
- Coenosia atrata
- Conophthorus
- Conophthorus edulis
- Crabro cingulatus
- Culex territans
- Dichagyris neoclivis
- Digrammia atrofasciata
- Exoprosopa painterorum
- Furcula scolopendrina
- Glena quinquelinearia
- Homochlodes disconventa
- Homorthodes dubia
- Icterica circinata
- Leptino
- Leptino orientamericanus
- Leucorrhinia patricia
- Melanocantón
- Melanocanthon nigricornis
- Myrmex floridanus
- Nemadus brachyderus
- Neoterpes ephelidaria
- Opomydas
- Opomydas townsendi
- Paracapnia
- Paracapnia opis
- Patrobinae
- Patrobus cinctus
- Pissonotus
- Pissonotus brunneus
- Plataea californiaria
- Platisoma
- Platisoma grácil
- Plectópteros
- Plectoptera picta
- Promachus painteri
- Psammodiini
- Psammodio
- Psammodius basalis
- Rhamphomyia nasoni
- Sumitrosis
- Sumitrosis pallescens
- Tesagrotis corrodera
Bob Webster ( talk ) 05:27 3 de febrero 2018 (UTC)
Discusión de Qbugbot
- En general, desaconsejamos enérgicamente la creación de códigos auxiliares de una línea, ya sea por humanos o por bot; La experiencia ha demostrado que rara vez, si es que alguna vez, se expanden posteriormente, y simplemente terminan siendo un desorden desatendido (y, en consecuencia, un imán de vandalismo) que obstruye las categorías, hace que Special: Random sea inutilizable y le da a Wikipedia una mala reputación. ¿Existe una ventaja específica en este caso (a) de tener un artículo de microtubo individual para cada una de estas especies en lugar de unas pocas listas largas a partir de las cuales se pueden crear y vincular artículos individuales si hay suficiente información sobre una especie en particular para justificar una posición? -artículo solo, y (b) hacerlo en Wikipedia (que en realidad no está diseñado para manejar este tipo de cosas) en lugar de en Wikispecies (que sí)? Si aún no lo ha hecho, le recomiendo leer Wikipedia: Village pump (policy) / Archive 66 # Automated creation of stubs , que es el hilo que creó la política actual cuando se trata de la creación masiva de artículos, y asegúrese de tener una respuesta para cada objeción que se planteó en ese entonces. - Iridiscente 09:02, 3 de febrero de 2018 (UTC)
- Muchas de estas inquietudes / preguntas se abordan en m: Wikispecies FAQ (que encontré en este BRFA de Ganeshk que ocurrió relativamente poco (7 meses) después de la discusión archivada de VPP vinculada anteriormente). Estoy seguro de que podemos encontrar muchos ejemplos de bots buenos y malos. La clave es una investigación rigurosa de la comunidad, que creo que ha estado y está sucediendo. ~ Tom.Reding ( talk ⋅ dgaf ) 14:44, 4 de febrero de 2018 (UTC)
- Apoyo firmemente el uso de este bot, después de una fase de prueba cuidadosa adecuada (como se planeó anteriormente). Hasta ahora, lo que he visto parece razonable. La discusión vinculada es de 2009 y ya pasamos 9 años; las objeciones allí parecen vagas. Los artículos son artículos, no importa si los hace un bot o un humano o un perro o un diablo: hay que juzgarlos por sus méritos. Los stubs generados por este bot parecen aún mejores que no tener nada. ¡Habla cíclope ! 11:44, 3 de febrero de 2018 (UTC)
- Asegúrese de que el bot publique información precisa; hemos tenido mala suerte en el pasado con artículos de especies creados en masa que están llenos de errores . También estoy dispuesto a oponerme a cualquier creación masiva de talones de una línea; por favor intente agregar más información. Jo-Jo Eumerus ( charla , contribuciones ) 12:02, 3 de febrero de 2018 (UTC)
- Soporte siempre que use Template: Speciesbox ( editar | hablar | historial | enlaces | ver | registros ) . Estos parecen mejores que los talones, casi comienzan. Nessie ( charla ) 13:25, 3 de febrero de 2018 (UTC)
- Hoy cambié de Taxobox a Speciesbox (y Taxobox automático para rangos más altos). Implica agregar a las plantillas de taxonomía, lo que debería ayudar a reducir los mensajes "no reconocidos" que los editores pueden encontrar al usar Speciesbox. Bob Webster ( charla ) 05:22, 4 de febrero de 2018 (UTC)
- ¡Súper! gracias @ Edibobb : ! Nessie ( charla ) 23:11, 4 de febrero de 2018 (UTC)
- Hoy cambié de Taxobox a Speciesbox (y Taxobox automático para rangos más altos). Implica agregar a las plantillas de taxonomía, lo que debería ayudar a reducir los mensajes "no reconocidos" que los editores pueden encontrar al usar Speciesbox. Bob Webster ( charla ) 05:22, 4 de febrero de 2018 (UTC)
- Como se señaló en las discusiones anteriores, también apoyo este concepto de bot. Son trozos de especies de alta calidad, ricos en referencias; no puede decirme que algo como Leptinus orientamericanus no es útil para el lector, incluso si solo hay una línea de texto propiamente dicha. Los artículos de género y de nivel superior con sus listas de taxones deberían ser especialmente bien recibidos. - Pero realmente deberíamos asegurarnos de que estos no tengan que pasar por la cola de NPP; de lo contrario, creo que esto acabaría por sí solo con la situación del atraso. - Elmidae ( charla · contribuciones ) 18:00, 3 de febrero de 2018 (UTC)
- Soporte tentativo : parecen talones de especies de muy alta calidad, pero me preocupa el impacto que esto tendría en New Page Patrol . Acabamos de luchar para pasar de un enorme atraso (22.000) a algo más razonable. Todavía no tenemos un control sobre él, con la acumulación de pedidos que se estancó alrededor de 3.5k. Estos stubs deberán ser revisados por un Patrullero de página nueva humano para detectar errores. Como mínimo, los artículos deben distribuirse durante un período de varios meses para no sobrecargar la NPP (durante 90 días, todavía se agregan 188 por día , a modo de comparación, actualmente tenemos que revisar alrededor de 350 cada día para mantenernos al día). No criticar el concepto, pero no enterrarnos en artículos nuevos (incluso si resultan ser casi completamente buenos). Yo por lo general opongo a conceder el bot autopatrolled. Estos artículos deben ser revisados por un humano al menos una vez en mi opinión. Arrastrarlo durante unos meses estará bien (aunque creo que sería ideal si todos los artículos agregados por bot para el día se agregaran a la misma hora ese día, para que se apilen y puedan revisarse como un bloque individual fácilmente). Inserte la frase clave aquí ( o aquí ) 19:43, 3 de febrero de 2018 (UTC)
- En efecto. A menos que todos confíen en el bot lo suficiente como para otorgarle el derecho de usuario de Autopatrolled, no lo haga. Matarás a WP: NPP . Mduvekot ( charla ) 20:03, 3 de febrero de 2018 (UTC)
- Si se concede el bot,
bot
lo habrá hechoautopatrol
, por lo que los artículos no aparecerán en la cola de NPP. - JJMC89 ( T · C ) 20:12, 3 de febrero de 2018 (UTC)
- Si se concede el bot,
- Soporte y soporte para otorgar el estado de patrullaje automático del bot, sobre la base de los artículos de ejemplo que se muestran arriba. Un punto menor: en Arhyssus scutatus , el marcado incluido
{{taxonbar|from=Q10417852}}
;{{taxonbar}}
será suficiente, como se muestra aquí . Es una lástima que {{ Taxobox }} todavía no obtenga sus datos de Wikidata. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 20:28, 3 de febrero de 2018 (UTC)- Con respecto a agregar los códigos Q a {{ taxonbar }} @ Pigsonthewing :, y quizás @ Tom.Reding : puedo responder mejor que yo, pero creo que el movimiento en esta dirección es para rastrear y mantener mejor los taxones con las próximas categorías de mantenimiento. Nessie ( charla ) 23:25, 3 de febrero de 2018 (UTC)
- El cambio que sugiero no debería influir en eso. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 01:30, 4 de febrero de 2018 (UTC)
- Gracias por la información sobre los códigos Q (y el soporte). El problema que tuve fue que, a menos que se especificara el Código Q, la barra taxonómica no aparecía en aproximadamente la mitad de las páginas. No entiendo por qué, así que acabo de agregar el código Q a todo lo que puedo. Bob Webster ( charla ) 05:22, 4 de febrero de 2018 (UTC)
- ¿Podría especificar una página en la que esto sucedió (o sucederá la próxima vez que lo note) para que podamos intentar recrear este comportamiento? ¿Quizás es solo un retraso entre Wikidata, Wikibase y Wikipedia para las páginas recién creadas?
- Parece que podría ser solo un retraso. Eliminé el código Q de algunas páginas creadas hace unos días, y taxonbar apareció bien (excepto por un par sin registros de Wikidata, que no tenían código Q para empezar). Hice lo mismo en algunas páginas creadas ayer (Acinia picturata, Schizura badia y Eucapnopsis), y el taxonbar no era visible sin el código Q. Bob Webster ( charla ) 15:40, 4 de febrero de 2018 (UTC)
- Mientras que el
|from=
/|from1=
no está parámetro requerido para {{ Taxonbar }}, que se desea de un seguimiento de perspectiva .|from=
/|from1=
solo debe eliminarse si la entidad Wikidata (código Q) no tiene relación con la página (es decir, se agregó erróneamente a {{ Taxonbar }}). ~ Tom.Reding ( talk ⋅ dgaf ) 06:14, 4 de febrero de 2018 (UTC)- El parámetro, que afecta a los datos mostrados, no debe responderse para su seguimiento; hacerlo puede tener consecuencias no deseadas. Considere, por ejemplo, el caso en el que se detecta un duplicado y, por lo tanto, los elementos de Wikidata se fusionan, o el enlace de Wikipedia se mueve a un elemento más apropiado en Wikidata. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 15:16, 4 de febrero de 2018 (UTC)
- Sí, esto es un inten consecuencia DED, y precisamente lo que se quiere realizar el seguimiento y la verificación.
- El comportamiento de {{ Taxonbar }} ha cambiado en el último mes o dos, en gran parte debido a los esfuerzos de Mellis , Ahecht , Peter coxhead y las discusiones de la comunidad. Una de las mejoras es que la entidad principal de Wikidata siempre se muestra como la fila superior, independientemente de
|from1=
. Además, nunca se muestran entidades duplicadas. Las discrepancias se derivan a una o más categorías de seguimiento (aunque aún no están activas). No existe una categoría de seguimiento para|from#=
valores duplicados , y probablemente debería agregarse en el futuro (aunque no es una prioridad ahora, ya que este es un caso muy marginal). Para obtener más información, le animo a leer los debates de Template talk: Taxonbar . ~ Tom.Reding ( talk ⋅ dgaf ) 15:56, 4 de febrero de 2018 (UTC)
- El parámetro, que afecta a los datos mostrados, no debe responderse para su seguimiento; hacerlo puede tener consecuencias no deseadas. Considere, por ejemplo, el caso en el que se detecta un duplicado y, por lo tanto, los elementos de Wikidata se fusionan, o el enlace de Wikipedia se mueve a un elemento más apropiado en Wikidata. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 15:16, 4 de febrero de 2018 (UTC)
- ¿Intentaste purgar las páginas afectadas? ¿Y artículos? Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 15:16, 4 de febrero de 2018 (UTC)
- ¿Podría especificar una página en la que esto sucedió (o sucederá la próxima vez que lo note) para que podamos intentar recrear este comportamiento? ¿Quizás es solo un retraso entre Wikidata, Wikibase y Wikipedia para las páginas recién creadas?
- Gracias por la información sobre los códigos Q (y el soporte). El problema que tuve fue que, a menos que se especificara el Código Q, la barra taxonómica no aparecía en aproximadamente la mitad de las páginas. No entiendo por qué, así que acabo de agregar el código Q a todo lo que puedo. Bob Webster ( charla ) 05:22, 4 de febrero de 2018 (UTC)
- El cambio que sugiero no debería influir en eso. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 01:30, 4 de febrero de 2018 (UTC)
- Con respecto a agregar los códigos Q a {{ taxonbar }} @ Pigsonthewing :, y quizás @ Tom.Reding : puedo responder mejor que yo, pero creo que el movimiento en esta dirección es para rastrear y mantener mejor los taxones con las próximas categorías de mantenimiento. Nessie ( charla ) 23:25, 3 de febrero de 2018 (UTC)
- Asistencia condicional , después de una discusión / consenso sobre el uso (o desuso o apatía hacia) plantillas estándar de WP: CS1 como {{ Cite journal }}, {{ Cite book }}, {{ Cite web }}, etc., por WP: ARTH y / o WP: TREE . Esto fue aludido en WT: ARTH # Adding Species Stub Articles por Jonesey95 (solo recientemente, sin embargo, VPP es un lugar más activo que WP: ARTH de todos modos). Personalmente, preferiría el uso completo de CS1 para mantenimiento y estandarización. Sin embargo, también me doy cuenta de que la mayoría de los otros talones de artrópodos probablemente (no he comprobado) también usan una combinación de forma libre y CS1, pero eso no significa que el patrón deba continuar. Al final, me someto al juicio colectivo de WP: ARTH / WP: TREE , y estoy en pleno apoyo (incluido el estado de WP: Autopatrolled ) siempre que el bot siga el consenso resultante. ~ Tom.Reding ( talk ⋅ dgaf ) 14:24, 4 de febrero de 2018 (UTC)
- ¡Gracias! He convertido el bot para usar {{ Cite journal }}, {{ Cite web }} y {{ Cite book }} para todas las referencias. Bob Webster ( charla ) 04:10, 7 de febrero de 2018 (UTC)
- Bob Webster , ¡bien hecho! Solo iba a publicar en WT: TREE para recibir más atención, pero ahora no es necesario. ¿Podría vincular a más de 10 páginas que su bot habría creado, tal vez pueda sobrescribir las páginas existentes que creó, que no tienen otras ediciones intermedias, con el nuevo código que incorpora plantillas de CS1? Preferiblemente, aquellos que sean representativos del posible espectro de las diferentes fuentes extraídas (es decir, las 10 que usan fuentes idénticas no serían útiles). Las plantillas pueden volverse muy exigentes a veces. La creación de una subsección separada a continuación o dentro de los artículos de # Muestra para estos también sería útil para otros que acaban de participar en la discusión. ~ Tom.Reding ( talk ⋅ dgaf ) 18:28, 7 de febrero de 2018 (UTC)
- Agregué algunos artículos de muestra a continuación y agradecería cualquier comentario o sugerencia. Bob Webster ( charla ) 02:07, 8 de febrero de 2018 (UTC)
- Además, en caso de que desee escanear muchas de las referencias, dejé algunos cientos de ellas (aproximadamente la mitad que estoy usando) aquí . Estaba usando Wikipedia para señalar algunos campos no válidos. Intentaré dejarlos por un par de días. Bob Webster ( charla ) 06:55, 8 de febrero de 2018 (UTC)
- Bob Webster , ¡bien hecho! Solo iba a publicar en WT: TREE para recibir más atención, pero ahora no es necesario. ¿Podría vincular a más de 10 páginas que su bot habría creado, tal vez pueda sobrescribir las páginas existentes que creó, que no tienen otras ediciones intermedias, con el nuevo código que incorpora plantillas de CS1? Preferiblemente, aquellos que sean representativos del posible espectro de las diferentes fuentes extraídas (es decir, las 10 que usan fuentes idénticas no serían útiles). Las plantillas pueden volverse muy exigentes a veces. La creación de una subsección separada a continuación o dentro de los artículos de # Muestra para estos también sería útil para otros que acaban de participar en la discusión. ~ Tom.Reding ( talk ⋅ dgaf ) 18:28, 7 de febrero de 2018 (UTC)
- ¡Gracias! He convertido el bot para usar {{ Cite journal }}, {{ Cite web }} y {{ Cite book }} para todas las referencias. Bob Webster ( charla ) 04:10, 7 de febrero de 2018 (UTC)
- Soporte , pero utilice el sistema de taxobox automático ({{ speciesbox }} para especies, {{ Automatic taxobox }} para taxones de nivel superior); esto requiere asegurarse de que existan plantillas de taxonomía apropiadas (también una tarea que un bot puede hacer) hasta el nivel de género; consulte Plantilla: Taxonomía / Polycestinae para obtener una muestra. עוד מישהו Od Mishehu 07:47, 5 de febrero de 2018 (UTC)
- ¡Gracias! El bot ahora usa {{ speciesbox }} para especies y {{ Automatic taxobox }} para taxones de nivel superior. Las plantillas de nivel superior se agregan según sea necesario. Bob Webster ( charla ) 04:10, 7 de febrero de 2018 (UTC)
- soporte débil Los ejemplos anteriores parecen ser resguardos adecuados y son mejores que algunos de los trabajos que se le ocurren a la gente. Preferiría no poner páginas que sean demasiado pequeñas. Sin embargo, alguien debería mirar la página en algún momento para ver si está bien. Graeme Bartlett ( charla ) 06:33, 7 de febrero de 2018 (UTC)
Agregué una nueva lista de artículos de muestra a continuación. El último código fuente está disponible en User: Qbugbot / source . ¡Gracias por las sugerencias! Por favor, avíseme si se encuentra con algo más. Bob Webster ( charla ) 19:32, 12 de febrero de 2018 (UTC)
Artículos de muestra de Qbugbot
Aquí hay una lista de algunos artículos de prueba aleatorios generados con qbugbot y publicados manualmente el 12 de febrero. Ahora incluyen los cambios recomendados a continuación por el monje trapense, Tom.Reding y Elmidae. Estos son los últimos de unos 2.000 artículos de talón de artrópodos que han sido generados por qbugbot y publicados manualmente desde el primero del año. Bob Webster ( charla ) 19:29, 12 de febrero de 2018 (UTC)
- Agonum nigriceps
- Amblytylus
- Amblytylus nasutus
- Andrena erythrogaster
- Anthonomus lecontei
- Araneus trifolium
- Axion
- Axion tripustulatum
- Bicyrtes viduatus
- Calycomyza solidaginis
- Carphoides incopriarius
- Celithemis verna
- Ceuthophilus chiricahuae
- Chrysotimus delicatus
- Coelioxys banksi
- Colidio
- Colydium robustum
- Corythucha juglandis
- Cucullia eulepis
- Dispar de diálisis
- Dicranoclista
- Dicranoclista fasciata
- Dictyna foliacea
- Efferia latrúncula
- Excirolana
- Excirolana chiltoni
- Glaucina lowensis
- Haematopota rara
- Hogna baltimoriana
- Hiperaspidio
- Hyperaspidius vittigerus
- Hyperaspis dissoluta
- Isoperla bilineata
- Keroplatus
- Keroplatus militaris
- Lebia perita
- Leia bivittata
- Leteo anthedon
- Melanoplus huroni
- Microfoto
- Microphotus decarthrus
- Neomegamelanus
- Neomegamelanus lautus
- Notiophilus intermedius
- Omophron solidum
- Orchelimum fidicinio
- Orthosia transparens
- Paquiceramia
- Pachyceramyia robusta
- Perdita rivalis
- Calcitas de Poecilus
- Psen erythropoda
- Pterostichini
- Rhynencina longirostris
- Rivellia munda
- Salina
- Salina mulcahyae
- Sphecodes mandibularis
- Symphoromyia hirta
- Tachytes intermedius
- Tricholochmaea rufosanguinea
- Ululodes
- Ululodes floridanus
- Tomando uno al azar, Tricholita chipeta , me pregunto si el algoritmo que seleccione la "lectura adicional" está realmente en el nivel. Aquí hay una serie de entradas de "Lecturas adicionales" que parecen irrelevantes, por ejemplo , esta , que trata de dos especies de la misma familia pero no tiene más conexiones. ¿Cómo se determinan estos? Este tipo de cosas deben evitarse. - De lo contrario, se ve bien, creo. - Elmidae ( charla · contribuciones ) 07:48, 8 de febrero de 2018 (UTC)
- Estás bien. Esta referencia y muchas otras se han asignado de forma demasiado amplia. La forma en que se ha hecho es que se selecciona el padre del taxón importante (el género, en este caso) y se asigna la referencia a todos sus descendientes (en este caso, la subfamilia Noctuinae). ¡Pero es una subfamilia enorme, y hay más de mil descendientes! No hace falta decir que estas dos nuevas especies no son aplicables a la mayoría de ellas. Estoy reasignando algunos cientos de referencias para ocuparme de situaciones como esta. Bob Webster ( charla ) 15:27, 9 de febrero de 2018 (UTC)
- No pude encontrar nada automáticamente incorrecto con estos; solo 5 WP menores que no valen la pena editar : GenFixes se encontraron en tantas páginas.
- A mano,
- Anthaxia viridifrons , Melanophilini , Phaenops californica : tenían etiquetas principales CS1 debido a
|date=2008-2009
, que simplemente deberían usar un guión en lugar de un guión. El uso de parámetros de volumen y número también (aunque no estoy seguro de si se necesitaba un guión corto ya que anteriormente se usó "No").|number=
- Smicronyx spretus , Lacinipolia triplehorni y otros: si la URL es un doi, sería útil incluirlo también como un doi (creo que hay bots que hacen esto)
- Hermetia hunteri , Lobophora nivigerata y posiblemente otras: ¿son
|pages=475
/|pages=1016
el número de páginas de los libros? (¡No deberían ser! Debería ser la ubicación del material de soporte solamente; de lo contrario, no pertenece; lo dejé solo por ahora) - Lacinipolia triplehorni , Metalectra bigallis y otras: los puntos se utilizan después de las iniciales en algunas plantillas, pero no en otras. ¿Puede estandarizar este uso página por página? (no hay error explícito aquí, solo una sugerencia)
- Sphaeroderus bicarinatus :
|pages=323 + 22 plates
parece extraño, pero no tengo sugerencias para nada más apropiado. ¿Alguien más puede comentar sobre esto? (|id=
existe, pero no parece apropiado) - Además, los puntos finales (es decir
|publisher=Houghton Mifflin Company.
) no son necesarios en las plantillas de CS1 (excepto para las abreviaturas), ya que la plantilla se encarga de toda la puntuación que de otro modo sería superflua. No se encontraron errores con respecto a esto, solo para su información para ayudar a evitar posibles errores futuros.
- Anthaxia viridifrons , Melanophilini , Phaenops californica : tenían etiquetas principales CS1 debido a
- También debería decir: ¡bien hecho! Y tan rápido también. ~ Tom.Reding ( talk ⋅ dgaf ) 17:59, 9 de febrero de 2018 (UTC)
- Bellamy no es un diario, por lo que es inapropiado. Debido a que viene en cinco volúmenes, mezclar la designación del volumen del libro con el número de edición de la serie de la editorial parece no tener sentido: 1–5 (76-80) implica que nos referimos a los números 75–80 de cada uno de los cinco volúmenes. cs1 | 2 no admite la noción de números de serie. Pensoft es el editor; serie, si es necesario, es Faunistica. Del mismo modo, Nelson, et al. también es un libro, no un diario; La Sociedad de Coleopteristas es la editorial.
{{cite journal}}
- Bellamy no es un diario, por lo que es inapropiado. Debido a que viene en cinco volúmenes, mezclar la designación del volumen del libro con el número de edición de la serie de la editorial parece no tener sentido: 1–5 (76-80) implica que nos referimos a los números 75–80 de cada uno de los cinco volúmenes. cs1 | 2 no admite la noción de números de serie. Pensoft es el editor; serie, si es necesario, es Faunistica. Del mismo modo, Nelson, et al. también es un libro, no un diario; La Sociedad de Coleopteristas es la editorial.
- Por lo general, las urls to dois no deben colocarse
|url=
cuando hay un|doi=
overlinking y porque la mayoría de los dois están detrás de muros de pago (|url=
generalmente se considera de lectura gratuita). Cuando el doi es de lectura libre, la cita debe marcarse con|doi-access=free
- Por lo general, las urls to dois no deben colocarse
|pages=323 + 22 plates
parece el problema del número total de páginas que se mencionó, por lo que no debe hacerse
- Los nombres de los editores no incluyen designaciones corporativas: 'Compañía', 'LLC', 'Ltd', 'Inc', etc.
- - Trapense el monje ( charla ) 13:21, 10 de febrero de 2018 (UTC)
Por favor mencione el sistema de clasificación en taxobox.
Tengo una solicitud para mejorar taxobox. En taxobox para taxones; debería mencionarse explícitamente; qué sistema de clasificación se ha utilizado. Si se ha realizado una combinación de sistemas (aunque no es muy recomendable). Es importante porque los sistemas de clasificación cambian; donde no solo los taxones se fusionan y se dividen; pero los rangos de los taxones a veces cambian; y aunque muy raramente; los nombres de rango también cambiaron. Así que cada vez que publique un taxobox; mencione qué sistema de clasificación se sigue. Es mejor si un taxobox contiene 2 o 3 columnas para las jerarquías de acuerdo con sistemas de clasificación separados. Esto no solo mejora la corrección de los artículos; pero también funcionará como una mejor referencia y ayudaría a la búsqueda de literatura.
RIT RAJARSHI ( charla ) 16:55, 13 de febrero de 2018 (UTC)
- Aclare lo que quiere decir con sistemas de clasificación. Es simplemente clasificado versus no clasificado, algo así como un escenario de sistema común versus sistema científico. - QEDK (後🌸桜) 19:29, 13 de febrero de 2018 (UTC)
- Si se usa Template: Speciesbox ( editar | hablar | historial | enlaces | ver | registros ) y Plantilla: Taxobox automático ( editar | hablar | historial | enlaces | ver | registros ) entonces las citas deben estar en la plantilla de taxonomía asociada. Nessie ( charla ) 20:01, 13 de febrero de 2018 (UTC)
Noté que el artículo sobre el idioma alemán tiene una muestra de audio hablada , pero muchos otros artículos relacionados con el idioma (como el español ) no lo tienen. ¿Sería bueno agregar muestras de audio a otros artículos que describen idiomas (incluidos los dialectos del inglés)? Los encuentro útiles porque ayudan a formar una imagen de cómo suena el idioma de destino. - Sir Beluga 16:26, 9 de febrero de 2018 (UTC)
- Puede etiquetar las páginas de discusión con {{ Audio solicitado }}. Nessie ( charla ) 21:26, 10 de febrero de 2018 (UTC)
- ¡Hola, señor Beluga ! Puede encontrar muestras de audio aquí , y más específicamente aquí . ¡Buena suerte! - NaBUru38 ( charla ) 00:44, 15 de febrero de 2018 (UTC)
Deshabilitar los mensajes dejados por InternetArchiveBot
- 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.
Este tema ha sido objeto de mucho debate, pero creo que deberíamos considerar desactivar la función que deja mensajes en las páginas de discusión.
Ver usuario: InternetArchiveBot para el contexto. Esta página de discusión muestra una instancia típica del proceso de mensajería del bot, que hace después de redirigir un enlace inactivo a una copia archivada de una página web inactiva alojada en Internet Archive . El bot ha publicado cientos de miles de estos mensajes en varias páginas de discusión de artículos de Wikipedia desde 2016.
¿Por qué?
- La tasa de error de IABot se ha reducido a números casi insignificantes.
- Los usuarios realmente interesados en comprobar la edición, lo harán sin que se les pida.
- Si el bot cometió un error, con la actualización más reciente de IABot en v1.6, simplemente revertir el bot es suficiente para informar una mala edición como un falso positivo.
Pregunta para ustedes, ¿debería desactivar la función de mensajería del bot? - Comentario anterior sin firmar agregado por Cyberpower678 ( charla • contribuciones ) 19:51, 11 de febrero de 2018 (UTC)
sí
- Soporte Los costos del bot que envía mensajes a la página de discusión son significativos y superan los beneficios. Cada vez que un usuario interactúa con un mensaje, ya sea leyéndolo, pasando para ignorarlo o siguiendo sus instrucciones, ese usuario está donando tiempo y trabajo a los proyectos de Wikimedia. Si un mensaje en promedio consume 1 segundo, entonces si hay 500,000 mensajes, eso son 140 horas de trabajo en esto. Dado que los mensajes permanecen en su lugar durante años, creo que en realidad consumen quizás 30 segundos cada uno en promedio a lo largo de sus vidas, lo que significa que los controles de este sistema de mensajería están consumiendo miles de horas de voluntariado de los usuarios. Si alguien aboga por mantener este sistema de mensajería en su lugar, pido a esas personas que hagan sus mejores estimaciones de los costos laborales para mantener el sistema de mensajería. Anteriormente planteé este problema en marzo de 2017 . En octubre de 2017, otras personas discutieron esto . Ahora la situación es aún más clara, ya que tenemos evidencia de que el bot casi nunca comete errores. Además, ahora este bot puede recibir alertas de las revisiones del registro del historial, lo que significa que la comunicación no tiene por qué suceder en la página de discusión y, en su lugar, puede ocurrir al deshacer o revertir sus ediciones. Siempre que un bot vaya a hacer algo en wiki cientos de miles de veces, tenemos que ser muy cuidadosos para estimar y medir cuánto trabajo de wiki crowdsourcing consumirán esas acciones de bot. En general, las acciones de los bots no pueden ser una pérdida de tiempo para la atención humana, y cualquier cosa que haga un bot debe aliviar el tiempo humano, no acumularlo. Los costos de mantener los mensajes de la página de discusión superan los beneficios que he visto a alguien describir. Siento que en el pasado, las personas que han abogado por mantener los mensajes tienen en mente que el valor del tiempo de voluntariado wiki es 0, o que se niegan a reconocer que es posible que la atención humana del editor de wiki tenga un valor que valga la pena cuantificar. De hecho, nuestro trabajo humano es extremadamente valioso y tenemos que protegerlo. IABot es increíble, gracias a todos por desarrollar este proyecto tanto técnica como socialmente. Blue Rasberry (charla) 20:01, 11 de febrero de 2018 (UTC)
- Soporte por nom y Blue Rasberry, y no olvidemos los costos para el operador y el WMF de realizar, almacenar y mostrar las ediciones de la página de discusión de esos artículos. - Jeff G. ツ20:32, 11 de febrero de 2018 (UTC)
- Apoyar el historial de revisión estándar es suficiente. power ~ enwiki ( π , ν ) 20:35, 11 de febrero de 2018 (UTC)
- Soporte . Nunca vi la razón para hacer esto, ya que casi nadie los revisa. El argumento era que lo serían ... pero no creo que haya ninguna evidencia de ello. Hay millones de enlaces muertos y miles cada mes. Dudo que estos mensajes estén siendo revisados. - HELL KNOWZ ▎ TALK 21:21, 11 de febrero de 2018 (UTC)
- Soporte Es esencialmente una duplicación de esfuerzos para el bot y los lectores de los mensajes de la página de discusión. Nihlus 21:23, 11 de febrero de 2018 (UTC)
- Soporte Sí, por favor. Son víctimas del propio éxito del bot y se han vuelto innecesarios. ~ Amory ( u • t • c ) 21:57, 11 de febrero de 2018 (UTC)
- Soporte Cada edición realizada por IABot, cada enlace de archivo que agrega, es revisado y verificado por WP: WAYBACKMEDIC . Sucede que sé exactamente cuál es la tasa de error :) Es lo suficientemente pequeña como para volver un poco loco a un humano tratando de buscar entre las buenas y las malas. Además, IABot tiene una herramienta en línea, una API y una base de datos donde gran parte de esta información está disponible. Si alguien quisiera saber "Muéstrame todos los enlaces de archivo en un artículo modificado por IABot", esa información está disponible, se podría crear una herramienta simple para mostrarla sin necesidad de saturar las páginas de discusión. - Green C 22:30, 11 de febrero de 2018 (UTC)
- Soporte Suponiendo una tasa de error muy baja. @ GreenC , Cyberpower678 : ¿qué es? ~ Tom.Reding ( talk ⋅ dgaf ) 23:15, 11 de febrero de 2018 (UTC)
- Mi tasa de error se basa en el número de informes de falsos positivos entrantes en relación con la tasa de edición general. Desde que se implementó IABot v1.6, detectaría automáticamente las reversiones realizadas por un usuario, identificaría al usuario que revertía e informaría cada cambio de enlace revertido como un posible falso positivo para que yo lo revisara. De los informes que llegaron, solo 3 o 4 fueron en realidad falsos positivos. Como GreenC dice que tiene el número exacto, dejaré que responda esa pregunta.— CYBERPOWER ( Be my Valentine ) 00:07, 12 de febrero de 2018 (UTC)
- Bueno ... ahora alguien tenía que preguntar :) Es complicado. Un problema es que no puedo decir que IABot haya agregado este enlace incorrecto y no otra persona. No pasa por el historial de revisiones. Sin embargo, en términos generales, WaybackMedic es capaz de "hacer algo" con aproximadamente el 2% de los enlaces de archivos para solucionar problemas. "Hacer algo" puede significar eliminar el archivo porque no funciona, agregar un archivo a un enlace inactivo, cambiar a un servicio de archivo diferente, cambiar la marca de tiempo, modificar la codificación de la URL, eliminar los caracteres basura en la URL (p. Ej., Al final ":" al final de una URL), etc. Sin embargo, muchas de estas causas raíz no tienen nada que ver con IABot. De todos modos, puedo verificar que aproximadamente el 98% de los enlaces de archivo en el sistema están funcionando y WaybackMedic puede arreglarlo para que supere el 99% (excepto para soft404 o verificar que el contenido coincida con la cita, que requiere controles humanos). - Green C 03:36, 12 de febrero de 2018 (UTC)
- Mi tasa de error se basa en el número de informes de falsos positivos entrantes en relación con la tasa de edición general. Desde que se implementó IABot v1.6, detectaría automáticamente las reversiones realizadas por un usuario, identificaría al usuario que revertía e informaría cada cambio de enlace revertido como un posible falso positivo para que yo lo revisara. De los informes que llegaron, solo 3 o 4 fueron en realidad falsos positivos. Como GreenC dice que tiene el número exacto, dejaré que responda esa pregunta.— CYBERPOWER ( Be my Valentine ) 00:07, 12 de febrero de 2018 (UTC)
- Soporte, pero el último que verifiqué Talk: List of Mountain Bothies Association bothies # Los enlaces externos modificados (enero de 2018) me parecieron completamente incorrectos. Espero que el sitio web al que se hace referencia no funcione en el momento de la verificación. No parecía haber una forma viable de informar el problema, por lo que el mensaje de conversación no ayudó. Thincat ( charla ) 23:37, 11 de febrero de 2018 (UTC)
- Hay una forma factible. Revertir la edición. IABot lo detectará y lo reportará automáticamente en su nombre.— CYBERPOWER ( Be my Valentine ) 00:07, 12 de febrero de 2018 (UTC)
- Eso es bueno entonces porque eso es lo que hice. No me di cuenta de que eso pasaría. Gracias. Thincat ( charla ) 08:14, 12 de febrero de 2018 (UTC)
- Hay una forma factible. Revertir la edición. IABot lo detectará y lo reportará automáticamente en su nombre.— CYBERPOWER ( Be my Valentine ) 00:07, 12 de febrero de 2018 (UTC)
- Apoyo débil , o quizás mantener el proceso de notificación pero poner el texto en un sobre para que los que lo deseen puedan abrirlo y revisarlo. GenQuest "Talk to Me" 04:23, 12 de febrero de 2018 (UTC)
- Soporte, gracias por el ping Bluerasberry. Lo más probable es que tarde o temprano alguien que se interese en el tema lo verifique. Puede haber ocasiones en las que resulte útil, pero en general parece una característica superflua. Reitero mi comentario de la última vez que intervine en esto diciendo que por lo general, si no siempre, hay mucho espacio para que el bot escriba en un enlace para que los usuarios hagan ping en busca de falsos positivos, a la ClueBot NG. Sin embargo, con los comentarios de OP de que una reversión simple funciona exactamente de la misma manera, encuentro que mis comentarios tienen aún más fuerza. Zeke , el terrorista loco (Habla rápido) (Sigue mi rastro) 05:28, 12 de febrero de 2018 (UTC)
- Apoyo Veo estos mensajes por todas partes, sin apenas comentarios. He comprobado un par, pero es poco probable que vuelva a comprobarlo. Todo lo mejor: Rich Farmbrough , 13:14, 12 de febrero de 2018 (UTC).
- Admite apagarlo a excepción de los mensajes realmente útiles. Nosotros no necesitamos botspam sentido de haber hecho las cosas triviales como proporcionado una dirección URL del archivo para una citar que no tienen uno, y otras acciones no controversiales. Si no es muy probable que necesite una revisión humana, no moleste a la página de discusión al respecto. Activa un flujo interminable de listas de seguimiento sin ningún motivo y es muy molesto. - SMcCandlish ☏ ¢ 😼 17:47, 12 de febrero de 2018 (UTC)
- Soporte , esto es principalmente un desorden en miles de millones de páginas de discusión. En su lugar, utilice un enlace de resumen de edición que apunte a una página de información si es necesario. Headbomb { t · c · p · b } 18:36, 12 de febrero de 2018 (UTC)
- Apoyo (un poco a regañadientes). Son ruidosos, tanto en las conversaciones como en la lista de observación de todos, se comen la preciosa atención del editor, se quedan para siempre y tienen muy poco propósito dada una tasa de error presumiblemente muy baja. Me gustaría mucho tener un "facilitador entusiasta" alternativo, pero en general creo que las desventajas superan con creces a las positivas. Sobre todo porque, en mi experiencia, la mayoría de los mensajes simplemente se ignoran: un beneficio potencial, pero no realizado , no supera las desventajas reales. - Xover ( charla ) 19:13, 12 de febrero de 2018 (UTC)
- Apoyo por las mismas razones que otros han expresado. Abarrota las páginas de discusión y no es particularmente controvertido. Killiondude ( charla ) 05:38, 13 de febrero de 2018 (UTC)
- Invocado por ping Desactívelo . Si bien entiendo el argumento de Xaosflux de que los costos monetarios / informáticos son bajos, creo que los costos humanos / de tiempo son demasiado altos. Estos mensajes se convierten rápidamente en mero ruido, por lo que creo que se omiten, lo que no genera gran beneficio al dejar el mensaje; Si una persona va a comprobar lo que ha hecho el bot, probablemente lo hará en presencia o ausencia de un mensaje, probablemente habiendo sido atraído a la página por una lista de seguimiento o comprobando el historial del artículo. Happy days, Lindsay Hola 09:05, 13 de febrero de 2018 (UTC)
- Soporte Es muy molesto e innecesario con pocos beneficios (si los hay). Casi pedí esto, pero al buscar en los archivos y ver que mucha gente había preguntado sin éxito, me di por vencido. Por favor, deténgalo lo antes posible. - Ammarpad ( charla ) 10:26, 13 de febrero de 2018 (UTC)
- Soporte por SMC. Ealdgyth - Charla 14:33, 13 de febrero de 2018 (UTC)
- Soporte ya que esto es demasiado trivial para que aparezca en la página de discusión de un artículo. La abrumadora mayoría de estas publicaciones de la página de discusión que he visto son ignoradas y, para la mayoría de los editores, no parecen tener otro propósito que crear desorden. La situación es similar a otros casos en los que es deseable que las ediciones menores sean revisadas en busca de errores, como la reversión del vandalismo de Cluebot, o la corrección de enlaces por parte del editor humano a las páginas de desambiguación (para los dabfixes que terminan en mi lista de observación, la tasa de error promedio es un orden de magnitud más alto que el límite superior establecido para la tasa de error de este bot y, sin embargo, nadie querría ver una publicación en la página de discusión por cada dablink arreglado). La única característica útil de estas publicaciones de la página de discusión es que permiten que un editor marque el enlace del archivo como verificado, para que otros editores no tengan que perder el tiempo revisando nuevamente. Pero, de manera realista, es probable que este excedente de editores ansiosos solo esté disponible en los artículos más populares; y en cualquier caso, cualquier forma de marcar un enlace de archivo como "revisado por un humano" sería mejor en la propia plantilla de enlace (en lugar de en la página de discusión). - Uanfala (charla) 19:30, 17 de febrero de 2018 (UTC)
No
- déjelo encendido A menudo compruebo el archivo y, en contraste con lo que podría pensar el médico de WAYBCK, una proporción significativa, quizás el 10% del archivo, no ha logrado producir un resultado útil. Claro que a menudo hay una página archivada, pero puede ser una página de consulta de base de datos sin una base de datos detrás, un mensaje de error que dice que la página no existe, un mensaje de ocupante ilegal de dominio o un shell de una página con todo el contenido dinámico que falta. En este tipo de casos, es mucho más difícil para un bot darse cuenta de que algo salió mal y un humano puede verlo fácilmente. Luego, necesitan rastrear dónde fue la página o la base de datos. El mensaje del bot ofrece un resumen adecuado que permite observar los resultados fácilmente. Solo mirar la página editada es mucho más difícil, ya que tienes que encontrar la aguja en el pajar del enlace modificado. ¡Quizás el mensaje podría ser menos detallado ocupando menos espacio en la página de discusión! Graeme Bartlett ( charla ) 22:52, 11 de febrero de 2018 (UTC)
- Este es un problema trivial. La solución es tener una página donde el bot registre estas cosas, y los gnomos que quieran limpiar después de ellos pueden ver esa página. Artículo por artículo, no hay ninguna diferencia. Un artículo con una fuente válida es 100% como fuente válida si el bot agrega una archiveurl inútil; esto no es algo sobre lo que los listas de seguimiento de un artículo en particular deban ser notificados, y de todos modos ya lo verán en las ediciones del artículo; ser notificado verbalmente al respecto es simplemente spam y sin sentido. - SMcCandlish ☏ ¢ 😼 17:50, 12 de febrero de 2018 (UTC)
- déjelo encendido , las actividades del bot son únicas entre los bots, ya que a menudo requieren verificación. El bot es tonto. Puede comprobar si hay un enlace muerto, pero no puede comprobar si hay un enlace mejor: tal vez el sitio haya reorganizado sus archivos, o esté en una nueva dirección de dominio, o incluso una búsqueda arroje una mejor. Para las referencias, esto no es tan importante: una referencia se puede verificar desde un enlace de archivo. Pero los enlaces externos generalmente están destinados a ser los mejores, por lo que los enlaces actuales y más actualizados para ese tema. Por lo tanto, es esencial que el bot informe lo que ha hecho, para garantizar que los editores tengan la oportunidad de verificarlo. Si los mensajes no se publican, el peligro es que las ediciones de los bots no se noten y se pasan por alto las oportunidades para corregir enlaces antiguos. Actualicé los enlaces de un par de artículos hace solo dos días, My Love Is a Bulldozer y My So-Called Life (álbum de Venetian Snares) , y es casi seguro que no lo haría si no hubiera un informe de la página de discusión, solo una entrada en el historial de la página .-- JohnBlackburne words hechos 23:04, 11 de febrero de 2018 (UTC)
- No estoy seguro de cómo me siento acerca de que llames tonto a mi robot. Si supiera cuánto código e inteligencia hay en esto, solo para hacer lo que hace ahora, cambiaría de opinión. Desafortunadamente, el bot nunca puede determinar cuál sería un mejor enlace, ya que necesitaría una infraestructura de clase de Google para lograrlo.— CYBERPOWER ( Be my Valentine ) 23:15, 11 de febrero de 2018 (UTC)
- Estúpido en la forma en que lo describí. Puede verificar que un enlace está inactivo, pero no tiene la inteligencia para averiguar por qué y encontrar a dónde se movió, o si hay un reemplazo mejor. Sí, ese nivel de IA está más allá de cualquier bot. Pero es por eso que es valioso verificar sus cambios, algo que sucedería con mucha menos frecuencia si el bot no dejara una nota. Se parecería a cualquier otro bot, que los editores están acostumbrados a ignorar .-- JohnBlackburne words hechos 23:59, 11 de febrero de 2018 (UTC)
- Cierto. Si la URL no redirige automáticamente a la nueva ubicación, el bot nunca sabrá que no está muerto.— CYBERPOWER ( Be my Valentine ) 00:09, 12 de febrero de 2018 (UTC)
- Estúpido en la forma en que lo describí. Puede verificar que un enlace está inactivo, pero no tiene la inteligencia para averiguar por qué y encontrar a dónde se movió, o si hay un reemplazo mejor. Sí, ese nivel de IA está más allá de cualquier bot. Pero es por eso que es valioso verificar sus cambios, algo que sucedería con mucha menos frecuencia si el bot no dejara una nota. Se parecería a cualquier otro bot, que los editores están acostumbrados a ignorar .-- JohnBlackburne words hechos 23:59, 11 de febrero de 2018 (UTC)
- No estoy seguro de cómo me siento acerca de que llames tonto a mi robot. Si supiera cuánto código e inteligencia hay en esto, solo para hacer lo que hace ahora, cambiaría de opinión. Desafortunadamente, el bot nunca puede determinar cuál sería un mejor enlace, ya que necesitaría una infraestructura de clase de Google para lograrlo.— CYBERPOWER ( Be my Valentine ) 23:15, 11 de febrero de 2018 (UTC)
- déjelo encendido : al igual que otros editores que preguntan lo mismo, lo uso como una oportunidad para ampliar las citas (especialmente cuando están en un idioma que no es el inglés). El bot no solo se vincula a menudo a un redireccionamiento archivado a una página de nivel superior, sino que también recoge páginas de error 404, etc. No puede confirmar que la cita sea RS (hay muchos casos en los que no lo son), ni ¿Puede saber si ha recogido el guardado correcto en una página dinámica? Tengo una acumulación de notificaciones en las que estoy trabajando lentamente (es un trabajo pesado, pero encontré muchos reemplazos para enlaces muertos y otros archivos problemáticos para artículos). Cuando agrego otro artículo a mi lista de seguimiento, reviso estas notificaciones en las que no se han marcado como marcadas. Probablemente se sorprenderá de la cantidad de veces que descubrí que el contenido ha sido manipulado posteriormente, o que las citas se falsifican intencionalmente o, como sucede con frecuencia en artículos que dependen de idiomas distintos del inglés, los errores de AGF se deben a un conocimiento deficiente del inglés que conduce a una mala traducción. Estoy seguro de que no soy el único editor que usa las indicaciones de la página de discusión como un método para ponerse al día con la integridad de un artículo. - Iryna Harpy ( charla ) 00:41, 12 de febrero de 2018 (UTC)
- Déjelo encendido : los mensajes de la página de discusión brindan una forma práctica de llegar a los enlaces afectados y verificarlos de manera eficiente. Sin embargo, no soy fanático de las entradas adicionales de la lista de seguimiento y estaría abierto a otro sistema para notar los enlaces afectados. Graham 87 02:30, 12 de febrero de 2018 (UTC)
- Déjelo encendido Los "costos" son totalmente teóricos y muy exagerados en base a cero investigaciones. El beneficio es que las acciones del bot son transparentes. Presentar un beneficio real de costo cero CBA se responde a sí mismo. Eggishorn (charla) (contrib) 15:50, 12 de febrero de 2018 (UTC)
- Déjelo Los bytes son baratos y los usuarios no están obligados a leer los mensajes si no quieren, y no veo el daño en dejar un aviso en las páginas de discusión. - Jayron 32 16:00, 12 de febrero de 2018 (UTC)
- Deje la transparencia de la acción del bot con el aviso y la respuesta que puedan necesitar los humanos vale incluso la desventaja afirmada, arriba. También es más probable que la respuesta conduzca a una mejora del bot. Alanscottwalker ( charla ) 16:07, 12 de febrero de 2018 (UTC)
- Déjelo encendido Los mensajes de la página de discusión del bot han proporcionado una sinopsis útil para verificar los enlaces. Si existe una sinopsis de este tipo en otro lugar, vincúlela en el resumen de edición y veamos si es un buen reemplazo, antes de desactivar la mensajería actual. Todavía encuentro ediciones cuestionables de IABot, aunque no las reviso con regularidad. Casi nunca corrijo sus ediciones revirtiendo, por lo que un sistema de registro de reversiones no es suficiente. En cualquier tipo de análisis de costo-beneficio, tendría que incluir el tiempo que tomarían los editores en vivo para mantener el tipo de viabilidad del enlace que IABot hace automáticamente. Incluso en su forma más imperfecta, era más eficiente que la verificación y actualización manual de enlaces. Dhtwiki ( charla ) 23:08, 12 de febrero de 2018 (UTC)
Discusión
Estoy haciendo ping a personas que han participado en conversaciones anteriores sobre los mensajes del bot.
- De Wikipedia: Bots / Noticeboard / Archive_11 # InternetArchiveBot_notices_about_nothing_but_archive-url_additions
- @ Francis Schonken , Graham87 , Rich Farmbrough , Hawkeye7 y Hasteur :
- @ SMcCandlish y Zeke, el terrorista loco :
- De Wikipedia: Village_pump_ (propuestas) / Archive_138 # Proposal _-_ non-required_automated_messages_on_talk_pages_must_be_short
- @ Xaosflux , GenQuest , Eggishorn , Od Mishehu y Godsy :
- @ Graeme Bartlett , LindsayH , Doc James y Jeff G .:
Blue Rasberry (charla) 20:07, 11 de febrero de 2018 (UTC)
- Meh , realmente no me importa de una manera u otra, si son útiles, guárdelos, si no, no lo haga. Sin embargo, no estoy muy de acuerdo con los argumentos sobre los "costos". - Charla xaosflux 21:06, 11 de febrero de 2018 (UTC)
- @ Xaosflux : Deseo evitar animarte a entrar en una conversación que no te parezca interesante, pero si estás abierto a la conversación, me gustaría saber más sobre tu opinión sobre los costes. Usted es un burócrata wiki cuyo papel incluye revisar bots, y estoy interesado en sus opiniones sobre hasta qué punto el consumo de bots de mano de obra humana influye en su decisión de aprobar bots.
- Estoy imaginando una ecuación donde
- (cantidad de tiempo humano que consume el bot) * (valor del tiempo humano) = costo del bot
- Tu opinión personal y tu opinión predeterminada pueden ser
- (los bots siempre consumen 0 tiempo humano) * (el tiempo humano tiene un valor de 0) = los bots siempre tienen 0 costo
- Mi punto de vista en esto es
- (10 segundos en promedio por publicación de IABot) * 500,000 publicaciones * US $ 15 / hr = 5,000,000 segundos * 15 / hr = bot consume trabajo humano con un valor de ~ $ 20,000
- Todo esto es una suposición, pero es un desafío para mí imaginar cómo las estimaciones más bajas podrían ser razonables. Cualquier estimación de tiempo o estimación del valor de la mano de obra multiplicada por 500.000 o 1.000.000 genera un coste elevado. Estoy viendo un llamado insostenible para la participación de la mano de obra humana en una actividad de bot altamente tediosa y no quisiera que los contribuyentes de wiki típicos se sientan atraídos por participar en interacciones sociales con bots en lugar de una actividad más humana que el entorno de wiki debería promover en su lugar. Ningún ser humano solicitará ayuda en voz alta un millón de veces, pero es posible que los bots lo hagan y, como regla general, defiendo que no deberíamos permitir que solicitudes automatizadas tan ruidosas compitan con la interacción de persona a persona. Si tiene otra visión del valor de las interacciones bot / humano u otros números para conectar en la ecuación, me gustaría escuchar lo que piensa, porque es un desafío para mí entender lo que significa socializar con bots que parecen expresivos. haciendo demandas de 10,000 a la vez. ¿Qué conocimiento tienes para detectar algún error en mi narrativa aquí? Blue Rasberry (charla) 23:17, 11 de febrero de 2018 (UTC)
- @ Bluerasberry : Reviso los bots como parte de BAG y no habría introducido un requisito para que este bot hiciera esto. En cuanto a los "costos" del espacio de almacenamiento en los servidores WMF, las tasas de edición / ancho de banda, etc., en general, si esto está causando un problema, el equipo de operaciones del servidor nos lo informará (rara vez lo es). En lo que respecta a los avisos de la página de discusión, los llenamos con todo tipo de cosas como pancartas de proyectos, información de clase reevaluada continuamente, etc. Nunca me han molestado ninguno de estos como editor, pero puedo ver dónde podrían hacerlo otros. No lo encuentro útil. Como dije anteriormente, si no es útil detenerse, es el camino a seguir. Y esta discusión es una buena manera de ayudar a determinar si es útil o no. En general, me opongo a obligar a un operador de bot a hacer una edición que no quieren (o abandonar las operaciones) a menos que haya una razón convincente de la comunidad por la que sea necesario. En este caso, el operador no quiere hacer estas ediciones, por lo que generalmente apoyo su solicitud. Espero que ayude. - xaosflux Talk 23:25, 11 de febrero de 2018 (UTC)
- @ Xaosflux : Siento que no he podido comunicarme con claridad. Me refiero a la mano de obra y el tiempo de los contribuyentes, mientras que usted parece haber comprendido que me refiero al costo de la electricidad. Deje de considerar los servidores, el procesamiento o cualquier cosa que no esté relacionada con el tiempo de los seres humanos individuales.
- La publicación de la página de discusión que IABot hace actualmente está en la familia del comportamiento de Chatbot o Spambot y el proceso de revisión de bots debe identificar y restringir la interacción social estilo spambot entre bots y humanos. En este momento estamos teniendo una conversación de humano a humano y ustedes están dando su trabajo a esto. El entorno wiki debería fomentar este tipo de interacciones. El entorno wiki no debe fomentar las interacciones humanas con los robots de spam. Los bots tienen el potencial de atraer a los humanos para que presten atención a tareas que ningún ser humano debería hacer. Desde el principio, este IAbot tuvo una tasa de fallas cercana al 0%, y ahora tiene una tasa de fallas mucho más cercana a 0, pero muy ruidosamente para muchos miles de usuarios, el bot solicitó su tiempo, atención y trabajo para verificar el funcionamiento del bot. Entiendo que la comunidad wiki fue cautelosa sobre la edición que hace este bot y que originalmente tenía sentido que el bot fuera cauteloso y divulgara información al ingresar al entorno wiki. No culpo a nadie por suponer que las publicaciones de la página de discusión serían útiles, pero cómo sabemos cómo pueden funcionar los bots, nunca quiero ver que ningún bot tenga en su diseño el objetivo de solicitar una gran cantidad de atención humana dirigida a las interacciones sociales con bots nunca más. La comunidad wiki debe tener cuidado de no permitir que nadie automatice miles de solicitudes que dirigen la atención humana a los bots. Si algún bot tiene inherente en su diseño la intención de solicitar cientos de horas de colaborador de Wikipedia, entonces creo que debería quedar claro en el proceso de revisión y que debería haber una evaluación sobre si miles de colaboradores de Wikipedia deberían prestar atención a las redes sociales. experiencia que el bot está poniendo frente a todos.
- Este bot ha realizado no menos de 500,000 publicaciones en la página de discusión cuando una publicación masiva típica es de 100 publicaciones. Esto es una locura fuera de la escala de lo que normalmente abordamos. Si cree que este bot está consumiendo una cantidad insignificante de tiempo, o si cree que la interacción humana con las publicaciones de este bot fue típicamente beneficiosa para el entorno wiki, me gustaría escuchar eso de usted.
- ¿Hasta qué punto estoy haciendo que mi inquietud sea fácil de entender? Blue Rasberry (charla) 00:20, 12 de febrero de 2018 (UTC)
- Ya dije que estoy a favor de permitir que este operador cambie esta tarea, salvo que exista un consenso de la comunidad de que es necesario, si la comunidad decide que estos mensajes son netamente positivos, no es mi lugar anularlos. Personalmente, no me importa si se quedan o se van. Las aportaciones de la comunidad a las tareas de bot propuestas en WP: BRFA siempre son bienvenidas, y BAG se esfuerza por garantizar que exista el apoyo de la comunidad para las tareas grandes, que siempre están disponibles para volver a revisarse. Parece un poco detallado, y creo que la mejor mejora sería que los operadores cambiaran para usar un enlace en su resumen de edición que vaya a una subpágina de preguntas frecuentes más expandida de la página de usuario del bot. Esto debería poder resumir el uso general y dar instrucciones para que las personas brinden mejor retroalimentación a los operadores. - Charla xaosflux 02:41, 12 de febrero de 2018 (UTC)
- @ Bluerasberry : Reviso los bots como parte de BAG y no habría introducido un requisito para que este bot hiciera esto. En cuanto a los "costos" del espacio de almacenamiento en los servidores WMF, las tasas de edición / ancho de banda, etc., en general, si esto está causando un problema, el equipo de operaciones del servidor nos lo informará (rara vez lo es). En lo que respecta a los avisos de la página de discusión, los llenamos con todo tipo de cosas como pancartas de proyectos, información de clase reevaluada continuamente, etc. Nunca me han molestado ninguno de estos como editor, pero puedo ver dónde podrían hacerlo otros. No lo encuentro útil. Como dije anteriormente, si no es útil detenerse, es el camino a seguir. Y esta discusión es una buena manera de ayudar a determinar si es útil o no. En general, me opongo a obligar a un operador de bot a hacer una edición que no quieren (o abandonar las operaciones) a menos que haya una razón convincente de la comunidad por la que sea necesario. En este caso, el operador no quiere hacer estas ediciones, por lo que generalmente apoyo su solicitud. Espero que ayude. - xaosflux Talk 23:25, 11 de febrero de 2018 (UTC)
- Pensando en voz alta: todavía estoy indeciso sobre esta cuestión. En general, me inclino a aceptar la posición del operador de bots asumiendo que tienen una visión superior del problema (y Cyberpower no cree que sirva para nada). Y de manera similar, me suscribo al principio de Xaosflux anterior: si el propietario de un bot no quiere hacer un tipo de edición, debería haber un interés comunitario muy convincente presente para justificar su obligación. También encuentro destacados los argumentos de Bluerasberry y los costos relacionados: tanto el costo técnico bruto de las ediciones adicionales, etc. (que es pequeño pero distinto de cero, y que puede llegar a ser no despreciable con el tiempo) y el costo humano del esfuerzo desperdiciado para lidiar con los avisos (pero no el esfuerzo cuando los humanos realmente intervienen por cualquier motivo). Dicho todo esto, sin embargo, sigo siendo ambivalente. Como premisa fundamental, no veo todas las ediciones en todos los artículos de mi lista de seguimiento. O incluso la mayoría de las ediciones de la mayoría de los artículos de mi lista de seguimiento. Simplemente hay demasiadas ediciones y demasiados artículos. Además, hay muy pocos editores trabajando en mi área, por lo que hay muy pocas probabilidades de que una edición dada reciba una revisión suficiente, o incluso cualquiera. Este es un problema importante en general (y se aplica a muchas áreas, no solo a mi pequeña subespecialidad), pero también se aplica a las ediciones de IABot (y en ausencia de una revisión significativa, no se puede saber cuál es la tasa de error aproximada real de IABot). En ese contexto, creo que quiero alguna forma de realizar un seguimiento de las actividades de IABot, en mi área, con una granularidad más burda que las ediciones individuales, pero no tan burda como para ser binaria. Los avisos de la página de discusión actual son los siguientes: persisten más allá de las ediciones individuales que se desplazan fuera de mi lista de seguimiento. Pero todavía se ocupan de una sola edición en un artículo. Entonces, ¿tal vez la configuración actual es demasiado fina? ¿Quizás un punto óptimo , para mí , sería un informe periódico (semanal, digamos) de la actividad de IABot en los artículos de mi WikiProject? Esto sería análogo al bot de alertas de artículos y las listas de limpieza. Eso me da un lugar para revisar periódicamente, y las ediciones de la página del informe aparecerán en mi lista de seguimiento si estoy trabajando activamente en Wikipedia; o si se actualiza en un intervalo predecible (como lo es la lista de limpieza), sabré verificarlo cuando el tiempo lo permita. Y no todos los artículos de mi lista de seguimiento están dentro del alcance de mi WikiProject, pero son los artículos del WikiProject los que me importan lo suficiente como para querer seguir esto de cerca. Para otros, puede haber agregaciones similares, como una categoría; pero una agregación de seguimiento / interés mayor que el artículo individual en cualquier caso. Y una agregación de cambios mayor que la edición individual (es decir, típicamente basada en el tiempo, incluso si el intervalo óptimo es algo diferente a mi preferencia para una semana). También hay problemas de "descubrimiento" (¿cómo encuentra la interfaz de herramientas de IABot? Un enlace en el resumen de edición versus un texto descriptivo permanentemente en la página de discusión son propuestas muy diferentes) y calidad (IABot es muy bueno, pero no es perfecto; todavía necesita humanos en el circuito, para "falsos negativos " y "otros" problemas, además de lo que anteriormente se llama "falsos positivos" por alguna razón). Pero estos son de menor importancia, creo. Entonces, ¿dónde me deja eso? Bueno, me deja indeciso, obviamente. ¿Quizás cyberpower678 podría intervenir sobre la viabilidad técnica y su interés (o falta, obviamente) en implementar algún tipo de sistema de informes? Y sería útil saber si otros tienen algún interés en algo como esto, o si la gran mayoría está simplemente en un lado o en el otro del binario Sí / No para editar los mensajes de la página de discusión. - Comentario anterior sin firmar agregado por Xover ( charla • contribuciones ) 06:18, 12 de febrero de 2018 (UTC)
- Hmmm ... No estoy dispuesto a crear uno en este momento. Muchos otros planes para IABot en este momento. Aunque honestamente, como dijo GreenC, la API de IABot permite que las herramientas accedan a información similar yendo a https://tools.wmflabs.org/iabot/api.php - CYBERPOWER ( Be my Valentine ) 13:39, 12 de febrero de 2018 (UTC)
- Documentación de la API: https://meta.wikimedia.org/wiki/InternetArchiveBot/API - Green C 16:06, 12 de febrero de 2018 (UTC)
- @ Cyberpower678 : Sí, me lo imaginé. ¿Tenerlo en cuenta como posible lista de deseos a largo plazo? En cualquier caso, no puedo ver nada en los documentos de la API que cubra el tipo de cosas que describo anteriormente. Estaría buscando algo como "¿Cuál de 'mis' artículos tuvo un enlace que no funcionó, o se agregó un archivo (que podría ser un archivo incorrecto), en los últimos 30 días?" La API, afaict, está totalmente orientada en torno a las URL y su estado actual, no a los artículos y su historia, si esa distinción tiene sentido. - Xover ( charla ) 19:04, 12 de febrero de 2018 (UTC)
- Hmmm ... No estoy dispuesto a crear uno en este momento. Muchos otros planes para IABot en este momento. Aunque honestamente, como dijo GreenC, la API de IABot permite que las herramientas accedan a información similar yendo a https://tools.wmflabs.org/iabot/api.php - CYBERPOWER ( Be my Valentine ) 13:39, 12 de febrero de 2018 (UTC)
- Solicité más comentarios en Wikipedia_talk: Bot_policy # Bots_that_consume_user_time, _and_request_for_comment y Wikipedia_talk: Bots / Requests_for_approval # Request_for_comment_about_Internet_Archive_Bot_messaging . Blue Rasberry (charla) 22:13, 16 de febrero de 2018 (UTC)
Discusión: Uso de rifles estilo AR-15 en tiroteos masivos
Se está llevando a cabo una discusión en:
- Wikipedia_talk: WikiProject_Firearms # Uso de rifles estilo AR-15 en tiroteos masivos
Se invita a participar a los editores interesados. - Kecoffman ( charla ) 20:29, 18 de febrero de 2018 (UTC)
Alias para casos de arbitraje
Siguiendo con la discusión en la charla de Wikipedia: Comité de Arbitraje / Tablón de anuncios / Archivo 36 # Comentarios de la comunidad: Propuesta sobre la denominación de casos , creé una plantilla de prueba de concepto para crear alias para los casos abiertos en 2017 y 2018. Consulte la charla de Wikipedia : Arbitraje / Solicitudes # Alias para casos de arbitraje para obtener más detalles. isaacl ( charla ) 02:28, 21 de febrero de 2018 (UTC)
Presupuesto de juegos y cambios en la representación de los presupuestos cinematográficos
Hola a todos, tengo dos sugerencias. ¿Deberíamos mostrar el presupuesto en las wikis para juegos de computadora? Esto ya está hecho en las wikis de películas.
Además, ¿debería tener una entrada especial para los costos de marketing cuando se habla de un presupuesto de película? Por ejemplo, podría decir que el presupuesto de una película es de 25 millones. La taquilla podría ser de 30 millones. Un lector de esta wiki podría creer que obtuvo una ganancia de 5 mil. Sin embargo, en el caso de las películas, el marketing suele ser el doble del presupuesto. Entonces, si el presupuesto de una película es de 25 millones + 25 millones de marketing, entonces tendría una pérdida de 30 millones. No 5 mil. lucro. Lo mismo se podría hacer con los juegos de computadora.
- Los desarrolladores de videojuegos rara vez publican esas cifras en medios confiables. Es algo que nos gustaría incluir si fuera posible bajo los requisitos de WP: RS . - Izno ( charla ) 12:10, 21 de febrero de 2018 (UTC)
- ¿No podrían simplemente agregarse a las respectivas plantillas de cuadro de información? Luego, si se encuentra información de origen, se puede incluir. Nessie ( charla ) 14:41, 21 de febrero de 2018 (UTC)
Hola a todos gracias por las sugerencias de respuestas. ¿Existe una forma sencilla de dar, por ejemplo, una plantilla de presupuesto a todos los juegos de ordenador? Y sí, por supuesto, estoy de acuerdo en que las fuentes de estos números deben ser confiables. Además, eventualismo estaría bien. Estoy bastante seguro de que puedo obtener fuentes confiables sobre los juegos más nuevos y más grandes para los más antiguos o más pequeños que podrían ser un poco más difíciles.
- Plantilla: el videojuego Infobox ( editar | hablar | historial | enlaces | ver | registros ) parece ser el que se va a editar. Si no está seguro de cómo, pregunte en la página de discusión. Nessie ( charla ) 14:06, 24 de febrero de 2018 (UTC)
RFC: Autocompletar Categoría: Plantillas de cuadro de información cuando podamos
Cunard ( charla ) 01:39, 12 de marzo de 2018 (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.
tl; versión dr: Propongo que cambiemos las plantillas de Categoría: Infobox a {{ todo incluido }} / {{ categoría de seguimiento }}, y obtengamos todos los beneficios que esto conllevaría.
Situación actual / Solución propuesta
Actualmente Categoría: Plantillas de imágenes está configurado como {{ categoría contenedor }} [con un puñado de infoboxes que son erróneamente en la categoría], que es casi completamente inútil. Los infoboxes están subcategorizados de una manera extremadamente incompleta, por lo que encontrar cualquier cosa es casi imposible simplemente porque este esquema es prácticamente ignorado, además de estar mal diseñado en general. Intente encontrar algo como {{ Infobox journal }} en la categoría principal, y pasará mucho tiempo navegando antes de darse cuenta de que se encuentra en
- Categoría: Plantillas de cuadro de información
- Categoría: Plantillas de cuadro de información de arte y cultura
- Categoría: Publicar plantillas de infobox
- Categoría: Plantillas de cuadro de información de arte y cultura
o
- Categoría: Plantillas de cuadro de información
- Categoría: Plantillas de cuadro de información de sociedad y ciencias sociales
- Categoría: Plantillas de cuadro de información de organización
- Categoría: Plantillas de cuadro de información de sociedad y ciencias sociales
Y ahí es cuando se categoriza en primer lugar. No puede acceder al {{ Equipo de ABL de Infobox }} porque no está categorizado.
Entonces, para arreglar / mejorar esta situación, propongo que cambiemos Categoría: plantillas de cuadro de información a {{ todo incluido }} / {{ categoría de seguimiento }}. Esto tendría varios beneficios, como (lista no exhaustiva):
- Todos los cuadros de información se enumerarían convenientemente directamente allí. Si está buscando algo relacionado con ABL, simplemente explore la categoría y busque ABL. Si está buscando {{ Revista Infobox }}, vaya a la sección M y busque revista.
- La categoría se podría buscar fácilmente con una
:incategory
llamada en Especial: Búsqueda . Si está buscando un cuadro de información relacionado con el comercio minorista, simplemente puede buscar 'comercio minorista' y encontrará {{ Mercado minorista de cuadro de información }} con bastante facilidad. - La categoría podría usarse para monitorear fácilmente los cambios recientes / vandalismo a través de las plantillas Special: RecentChangesLinked / Category: Infobox .
- Luego, WP: AALERTS podría usar la categoría para crear alertas de artículos para los cuadros de información de WP: WikiProject .
La categoría podría completarse automáticamente y ordenarse correctamente por la propia plantilla {{ Infobox }} (y otras plantillas similares) en la gran mayoría de los casos (al menos cualquier cosa que comience con Plantilla: Infobox foobar puede ser), con el resto ser categorizado manualmente. Esto no cambiaría el sistema de subcategorías, por lo que los editores aún podrían encontrar {{ Infobox element }} a través de
- Categoría: Plantillas de cuadro de información
- Categoría: Plantillas de infobox de ciencia y naturaleza
- Categoría: Plantillas de cuadro de información de química
- Categoría: Plantillas de cuadro de información de tabla periódica
- Categoría: Plantillas de cuadro de información de química
- Categoría: Plantillas de infobox de ciencia y naturaleza
si prefieren navegar de esa manera. Headbomb { t · c · p · b } 12:43, 21 de febrero de 2018 (UTC)
! Vote (categorización de Infobox)
- Apoyo , según propone. Headbomb { t · c · p · b } 12:44, 21 de febrero de 2018 (UTC)
Actualmente neutral .Cambiando a soporte después del comentario de Headbomb . Jc86035 ( charla ) 14:39, 21 de febrero de 2018 (UTC) Hay al menos 100 infoboxes que no usan Module: Infobox pero usan class = "infobox" (1,107 plantillas en total), por lo que el seguimiento tendría que contabilizar manualmente aquellos y posiblemente otros que no usan la clase CSS de infobox. Esta consulta PetScan de ejemplo enumera todas las plantillas de Categoría: Plantillas de cuadro de información cuyo título contiene la palabra "cuadro". Los puntos de alerta de vandalismo / artículos parecen ligeramente útiles, aunque Special: RecentChanges con los nuevos filtros (espacio de nombres de plantilla, excluyendo editores 500/30) probablemente sea suficiente para encontrar vandalismo, ya que de todos modos no hay mucha actividad de edición en el espacio de nombres de Plantillas. Jc86035 ( conversación ) 13:25, 21 de febrero de 2018 (UTC)- Esa es una limitación de la parte 'automática', pero esos casos se pueden manejar manualmente con bastante facilidad. En realidad, se manejan mejor manualmente, ya que no todo lo que tiene una clase de cuadro de información es en realidad un cuadro de información (p. Ej., {{ Tema de navegación del año }} [un cuadro de navegación], {{ RFA }} [que incluye una sección del cuadro de navegación], {{ Polonia etiquetado Mapa pequeño }} [un mapa], etc.). Sin embargo, lo de RecentChanges también se aplica a más que solo monitorear el vandalismo, y hay otros beneficios para esto más allá de un registro de RecentChanges más útil para infoboxes. Lo que me motivó personalmente es que quiero configurar WP: AALERTS para los Infoboxes de WikiProject , y esta sería una forma mucho más eficiente de hacerlo que cualquier otra cosa que tengamos. Headbomb { t · c · p · b } 13:42, 21 de febrero de 2018 (UTC)
- Soporte - Por nominador.
Saludos, SshibumXZ ( Charla ) ( Contribuciones ). 20:39, 21 de febrero de 2018 (UTC) - Soporte - Múltiples aspectos positivos, ningún incidente negativo. ~ Tom.Reding ( talk ⋅ dgaf ) 00:38, 22 de febrero de 2018 (UTC)
- Soporte - Por nominador. ∰ Bellezzasolo ✡ Discutir 11:44, 22 de febrero de 2018 (UTC)
- Soporte : esta parece una muy buena idea con poco o ningún inconveniente.- Mr X 🖋 13:27, 22 de febrero de 2018 (UTC)
- Soporte Teniendo en cuenta la pesadilla absoluta que es hacer una nueva categorización de páginas, buscar aquí y allá para averiguar cómo alguien clasificó las categorías, o incluso qué categorías hay, apoyaría cualquier cosa que lo haga más fácil. Si lo mejor que podemos hacer es un solo grupo a través de Crtl-F, bueno, tomaré lo que pueda conseguir. Jbh Talk 23:29, 23 de febrero de 2018 (UTC)
- Soporte Bien argumentado, claramente beneficioso, sin aparentes desventajas. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 00:09, 24 de febrero de 2018 (UTC)
- Oponerse de esta forma. Objeciones fundamentales: aún falta la definición central para incluir / excluir (la propuesta no dice: "todas las plantillas que usan
class=infobox
", o de otro modo). No existe ninguna disposición para agregar / eliminar "esquineros" *, que podrían manejarse mejor de antemano en la etapa de definición (es decir, aquí y ahora). Además, la categoría cambiará su definición sin proporcionar ningún proceso de limpieza / ajuste de las subcategorías; estos se dejan morir sin cuidado (para esto también, comenzar una nueva categoría sería una mejor solución, evadiendo definiciones contradictorias).
- Como muestran las discusiones preliminares de la página de conversación, este ejemplo se originó con la "automatización", no con la "redefinición". Una lástima que no se haya corregido ahora, aunque debo decir que se abordan algunos problemas incidentales iniciales.
- * Los ejemplos de 'Cornercase' son, cada uno de un motivo / origen diferente (es decir, cada ejemplo aquí representa un solo problema): {{ Taxobox }}, {{ Chembox }}, {{ Infobox3cols }}, Wikipedia: Manual de estilo / Infoboxes , {{ PBB / 2239 }}, {{ Encabezado de esquema }}, {{ Usuario / zona de pruebas de Wikipedia de Infobox }}, {{ Medicamento / licencia de Infobox }}. - DePiep ( charla ) 12:30, 25 de febrero de 2018 (UTC)
- Como se explicó anteriormente, no todo lo que tiene la clase infobox es un infobox, por eso la propuesta dice todos los infoboxes , en lugar de todas las plantillas con un
class=infobox
en alguna parte . En cuanto a sus esquineros, esto también se ha explicado anteriormente. Estos se pueden manejar agregando[[Category:Infobox templates]]
manualmente a las plantillas (o subpáginas) cuando sea apropiado. Headbomb { t · c · p · b } 23:09, 25 de febrero de 2018 (UTC)- Entonces, ¿qué no definir algo ser una caja de información? Además, no todos los "esquineros" se resuelven arriba (y tengamos en cuenta que los "esquineros" no son excepciones. Pueden constituir el 50% de todos los infoboxes. - DePiep ( charla ) 11:40, 26 de febrero de 2018 (UTC)
- Ver WP: INFOBOX . Headbomb { t · c · p · b } 12:14, 26 de febrero de 2018 (UTC)
- Autocontradictorio: WP: INFOBOX se trata de artículos, por lo que los cuadros fuera del espacio principal no son cuadros de información por definición (etcétera: como predije, ahora todos los 'esquineros' deben manejarse con un argumento uno por uno). Este nudo podría evitarse definiendo primero qué infoboxes deben categorizarse. Además, todavía no hay respuesta sobre cómo se tratarán los contenidos de la subcategoría. (Por cierto, el patrón de razonamiento en este tema es el siguiente: A. Se hace alguna declaración, B. Apunto a un tema problemático, C. Respuesta: no, eso no es un problema y se resolvería de tal o cual manera). - DePiep ( charla ) 20:51, 26 de febrero de 2018 (UTC)
- En este punto, claramente estás trolleando. WP: INFOBOX se trata de infoboxes, no de artículos. Para citar "Un cuadro de información es un panel, generalmente en la parte superior derecha de un artículo, junto a la sección principal (en la versión de escritorio de Wikipedia) o al final de la sección principal de un artículo (en la versión móvil), que resume las características clave del tema de la página ". Con respecto a "no hay respuesta sobre cómo se tratará el contenido de la subcategoría", está cubierto por "Esto no cambiaría el sistema de subcategorías" arriba y "Todas las demás categorías permanecerían sin cambios" a continuación. Empiece a tener sentido o aléjese. Headbomb { t · c · p · b } 22:10, 26 de febrero de 2018 (UTC)
- Otro ejemplo. El OP dice: "[con un puñado de infoboxes que están erróneamente en la categoría]". Claramente, eso está cambiando la definición de esta categoría, todavía no quiere reconocer. En total, enumeré ocho situaciones diferentes, cada una se tropieza con una "explicación" que no se sostiene. - DePiep ( charla ) 11:00, 27 de febrero de 2018 (UTC)
- ¿Se niega a reconocer? De eso se trata toda la propuesta. Cambio de categoría: plantillas de cuadro de información de una categoría de contenedor a una categoría que contiene todos los cuadros de información. Headbomb { t · c · p · b } 12:19, 27 de febrero de 2018 (UTC)
- Otro ejemplo. El OP dice: "[con un puñado de infoboxes que están erróneamente en la categoría]". Claramente, eso está cambiando la definición de esta categoría, todavía no quiere reconocer. En total, enumeré ocho situaciones diferentes, cada una se tropieza con una "explicación" que no se sostiene. - DePiep ( charla ) 11:00, 27 de febrero de 2018 (UTC)
- En este punto, claramente estás trolleando. WP: INFOBOX se trata de infoboxes, no de artículos. Para citar "Un cuadro de información es un panel, generalmente en la parte superior derecha de un artículo, junto a la sección principal (en la versión de escritorio de Wikipedia) o al final de la sección principal de un artículo (en la versión móvil), que resume las características clave del tema de la página ". Con respecto a "no hay respuesta sobre cómo se tratará el contenido de la subcategoría", está cubierto por "Esto no cambiaría el sistema de subcategorías" arriba y "Todas las demás categorías permanecerían sin cambios" a continuación. Empiece a tener sentido o aléjese. Headbomb { t · c · p · b } 22:10, 26 de febrero de 2018 (UTC)
- Autocontradictorio: WP: INFOBOX se trata de artículos, por lo que los cuadros fuera del espacio principal no son cuadros de información por definición (etcétera: como predije, ahora todos los 'esquineros' deben manejarse con un argumento uno por uno). Este nudo podría evitarse definiendo primero qué infoboxes deben categorizarse. Además, todavía no hay respuesta sobre cómo se tratarán los contenidos de la subcategoría. (Por cierto, el patrón de razonamiento en este tema es el siguiente: A. Se hace alguna declaración, B. Apunto a un tema problemático, C. Respuesta: no, eso no es un problema y se resolvería de tal o cual manera). - DePiep ( charla ) 20:51, 26 de febrero de 2018 (UTC)
- Ver WP: INFOBOX . Headbomb { t · c · p · b } 12:14, 26 de febrero de 2018 (UTC)
- Entonces, ¿qué no definir algo ser una caja de información? Además, no todos los "esquineros" se resuelven arriba (y tengamos en cuenta que los "esquineros" no son excepciones. Pueden constituir el 50% de todos los infoboxes. - DePiep ( charla ) 11:40, 26 de febrero de 2018 (UTC)
- Como se explicó anteriormente, no todo lo que tiene la clase infobox es un infobox, por eso la propuesta dice todos los infoboxes , en lugar de todas las plantillas con un
- Haga de esto una objeción permanente . El nom no ha mostrado ninguna intención de mejorar la propuesta después de haber señalado importantes defectos de diseño. También enumeré unas ocho situaciones de excepción, y tengo que tirar de todas y cada una de las respuestas que luego resultan ser "la gente sabe", asumiendo obviedad, contradicción, etcétera, en lugar de crear una base sólida. - DePiep ( charla ) 11:00, 27 de febrero de 2018 (UTC)
- Support DePiep parece estar bien informado sobre los casos en los que la regla general no se aplicará y esos casos merecen una atención adicional e inusual. Sin embargo, hasta donde tengo entendido, la propuesta general que se hace aquí se aplica a muchos casos, y su implementación normalmente traerá mejoras. Parece razonable promulgar esto en una escala de cientos de infoboxes. Blue Rasberry (charla) 00:42, 26 de febrero de 2018 (UTC)
- Uno de los argumentos es que la lista de una sola categoría es útil en el seguimiento automático. Aún no se hace ni se propone ningún esfuerzo para incluir todos los infoboxes de forma sistemática. Solo hay una única propuesta de automatización, el resto se deja solo (ambas páginas para incluir y páginas para excluir). Los esquineros que mencioné representan un problema descubierto cada uno. En lugar de asumir implícitamente una docena de soluciones ("¿qué hacemos con / sandboxes?"), La solución de principio es definir 'qué es un infobox para categorizar'. Además, omitir una definición de categoría de sonido aumenta el caos entre la categoría superior y sus subcategorías actuales. Eso no es una mejora. - DePiep ( charla ) 11:40, 26 de febrero de 2018 (UTC)
- Esto se debe principalmente a que la gente sabe qué son los infoboxes y son muy conscientes de que los sandboxes no deben clasificarse en la categoría principal, al igual que los borradores deben excluirse en las categorías de espacio principal. Headbomb { t · c · p · b } 12:17, 26 de febrero de 2018 (UTC)
- Respondido en la viñeta anterior. - DePiep ( charla ) 20:51, 26 de febrero de 2018 (UTC)
- re
la gente sabe qué son los infoboxes
; aparentemente, ese conocimiento es diferente. Por ejemplo, difiere entre usted y yo, y entre formularios de plantilla. En general, "la gente sabe" no es una base sólida para una definición (redefinición de categoría en este caso). Además, mencioné ocho situaciones no estándar, de las cuales ninguna ha sido respondida con la definición de categoría. - DePiep ( charla ) 11:12, 27 de febrero de 2018 (UTC)- Solo parece diferir entre usted y el resto de wikipedistas. Si no sabe qué es un cuadro de información, probablemente debería evitar comentarlo hasta que sepa lo que es. Ninguna de sus situaciones "no estándar" causa problemas con esta propuesta. {{ Taxobox }}, {{ Chembox }}, {{ PBB / 2239 }}, son infoboxes y se clasificarían y ordenarían en consecuencia. {{ Encabezado de esquema }} parece ser un cuadro de navegación y probablemente no estaría categorizado (de todos modos no se usa, por lo que probablemente podría simplemente eliminarse). Pero si la comunidad lo considera un infobox, entonces se categorizaría. {{ Usuario / zona de pruebas de Wikipedia de Infobox }} es una zona de pruebas y no se clasificaría (aunque {{ Usuario de Wikipedia de Infobox }} sí lo estaría). {{ Infobox3cols }} es una metaplantilla de infobox como {{ infobox }} y obtendría el mismo tipo de actualización que {{ infobox }} y permanecería categorizada como está actualmente (en la parte superior de la categoría). {{ Infobox fármaco / licencia }} es una sub-plantilla utilizada por un infobox y no se clasificaría. WP: Manual of Style / Infoboxes es una guía de estilo sobre infoboxes, y aunque no es un infobox en sí mismo, es parte de un pequeño conjunto de pautas básicas relacionadas con infoboxes, y permanecería categorizado como está actualmente (en la parte superior de la categoría , junto con otras páginas similares). Esto es obvio para todos menos para ti. Headbomb { t · c · p · b } 12:02, 27 de febrero de 2018 (UTC)
- re
- Respondido en la viñeta anterior. - DePiep ( charla ) 20:51, 26 de febrero de 2018 (UTC)
- Esto se debe principalmente a que la gente sabe qué son los infoboxes y son muy conscientes de que los sandboxes no deben clasificarse en la categoría principal, al igual que los borradores deben excluirse en las categorías de espacio principal. Headbomb { t · c · p · b } 12:17, 26 de febrero de 2018 (UTC)
- Uno de los argumentos es que la lista de una sola categoría es útil en el seguimiento automático. Aún no se hace ni se propone ningún esfuerzo para incluir todos los infoboxes de forma sistemática. Solo hay una única propuesta de automatización, el resto se deja solo (ambas páginas para incluir y páginas para excluir). Los esquineros que mencioné representan un problema descubierto cada uno. En lugar de asumir implícitamente una docena de soluciones ("¿qué hacemos con / sandboxes?"), La solución de principio es definir 'qué es un infobox para categorizar'. Además, omitir una definición de categoría de sonido aumenta el caos entre la categoría superior y sus subcategorías actuales. Eso no es una mejora. - DePiep ( charla ) 11:40, 26 de febrero de 2018 (UTC)
Discusión (categorización de Infobox)
- Comentario: Subcategorías Categoría: Plantillas de infobox por ... , para agrupar jerarquías de infobox por diferentes facetas, también puede ser útil. Jheald ( charla ) 13:12, 21 de febrero de 2018 (UTC)
- Comentario: Probablemente sea mejor crear una nueva categoría de seguimiento pero no cambiar las categorías existentes. Ruslik _ Zero 20:32, 23 de febrero de 2018 (UTC)
- ¿Por qué sería mejor? Tenemos una categoría existente. No hay inconveniente en usar ese y hacerlo útil. Headbomb { t · c · p · b } 22:39, 23 de febrero de 2018 (UTC)
- La autocategorización parece un medio para llegar a un fin dado que el objetivo es configurar alertas de artículos. Otra solución sería simplemente agregar la categoría manualmente. Otra alternativa sería monitorear Special: Recentchangeslinked for Template: Infobox (muchas protecciones hoy por Primefac), considerando que estas plantillas no se cambian mucho , como es posible que necesite alertas de artículos para un WikiProject genérico (para filtrar el ruido del eventos de página importantes como XFD). Las comprobaciones de nuevos infoboxes utilizando {{ infobox }} sin la categoría se pueden realizar desde Especial: Búsqueda .
Independientemente de la implementación de una categoría "todos los infoboxes", apoye el comentario de Ruslik: Debería ser Categoría: Todas las plantillas de infobox . - Izno ( charla ) 21:21, 23 de febrero de 2018 (UTC) - @ Headbomb : ¿Puedes seguir con tu ejemplo de {{ Infobox journal }} y describir cómo cambiaría la categorización de esa plantilla después de los cambios que propones? Blue Rasberry (charla) 21:45, 23 de febrero de 2018 (UTC)
- @ Bluerasberry : No estoy muy seguro de lo que se pregunta aquí exactamente. Lo único diferente sería que {{ Diario de Infobox }} se categorizaría en Categoría: Plantillas de Infobox , ordenadas bajo 'Diario'. Todas las demás categorías se mantendrían sin cambios. Bomba de cabeza { t · c · p · b }
- @ Headbomb : Le pido que hable sobre los cambios en {{ Infobox journal }} como ejemplo. Parece que está proponiendo agregar [[Categoría: Plantillas de cuadro de información | Revista]] a {{ Revista de cuadro de información }}, ¿verdad? Blue Rasberry (charla) 23:13, 23 de febrero de 2018 (UTC)
- @ Bluerasberry : No, eso lo haría {{ Infobox }} automáticamente. No se necesitarían modificaciones en {{ diario de Infobox }}. Headbomb { t · c · p · b } 23:19, 23 de febrero de 2018 (UTC)
- @ Headbomb :, Está bien, entonces no agregará esa categoría directamente, pero el cambio que está proponiendo colocará indirectamente ese artículo en esa categoría, ¿correcto? Blue Rasberry (charla) 23:21, 23 de febrero de 2018 (UTC)
- Correcto. Habrá algunos casos de esquina que deberán manejarse manualmente, pero esos son minoritarios. Headbomb { t · c · p · b } 23:24, 23 de febrero de 2018 (UTC)
- @ Headbomb : Bien, y en general, la clasificación será del formato "
InfoboxWhatever", que es el nombre de la plantilla menos la palabra "infobox", ¿verdad? ¿Y estás diciendo que la minoría de casos manuales serán los que por alguna razón no tienen ese tipo de nombre típico? Blue Rasberry (charla) 13:42, 24 de febrero de 2018 (UTC)- Bastante, sí. Headbomb { t · c · p · b } 14:52, 24 de febrero de 2018 (UTC)
- Gracias. Blue Rasberry (charla) 00:42, 26 de febrero de 2018 (UTC)
- Bastante, sí. Headbomb { t · c · p · b } 14:52, 24 de febrero de 2018 (UTC)
- @ Headbomb : Bien, y en general, la clasificación será del formato "
- Correcto. Habrá algunos casos de esquina que deberán manejarse manualmente, pero esos son minoritarios. Headbomb { t · c · p · b } 23:24, 23 de febrero de 2018 (UTC)
- @ Headbomb :, Está bien, entonces no agregará esa categoría directamente, pero el cambio que está proponiendo colocará indirectamente ese artículo en esa categoría, ¿correcto? Blue Rasberry (charla) 23:21, 23 de febrero de 2018 (UTC)
- @ Bluerasberry : No, eso lo haría {{ Infobox }} automáticamente. No se necesitarían modificaciones en {{ diario de Infobox }}. Headbomb { t · c · p · b } 23:19, 23 de febrero de 2018 (UTC)
- @ Headbomb : Le pido que hable sobre los cambios en {{ Infobox journal }} como ejemplo. Parece que está proponiendo agregar [[Categoría: Plantillas de cuadro de información | Revista]] a {{ Revista de cuadro de información }}, ¿verdad? Blue Rasberry (charla) 23:13, 23 de febrero de 2018 (UTC)
- @ Bluerasberry : No estoy muy seguro de lo que se pregunta aquí exactamente. Lo único diferente sería que {{ Diario de Infobox }} se categorizaría en Categoría: Plantillas de Infobox , ordenadas bajo 'Diario'. Todas las demás categorías se mantendrían sin cambios. Bomba de cabeza { t · c · p · b }
- 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.
Agregar enlace para la búsqueda en Wikidata
RFC aquí, únase -> MediaWiki_talk: Wdsearch.js # Add_link_to_search . - Superchilum ( ¡háblame! ) 10:50, 28 de febrero de 2018 (UTC)
1 de abril ... Wikipedia como Viewdata (¿Página 100 para la página principal?)
- 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.
Como mucha gente aquí sabe, hay artículos ocasionales del 1 de abril publicados en Wikipedia en inglés,
Sin embargo, este año quería preguntar si habría algún interés en hacer algo un poco inusual.
Durante la década de 1980 en el Reino Unido existía un sistema de visualización de datos llamado Prestel , que utilizaba una presentación
formato no muy diferente al sistema de teletexto utilizado por el CEEFAX "over the air" de la BBC .
Me interesaría ver el 1 de abril cómo podría haber sido la Wikipedia en inglés como un sistema basado en datos de visualización c. 1988.
Publiqué una propuesta similar en la Wikipedia francesa (aunque por razones obvias el sistema base sería el francés TeleTel / Minitel)
Necesitaría una cantidad moderada de esfuerzo técnico, ya que actualmente Commons no admite necesariamente una vista para los formatos de cuadros de teletexto que admite el editor de cuadros GPL que encontré.
ShakespeareFan00 ( charla ) 10:59, 27 de febrero de 2018 (UTC)
- Me gusta. El viejo "Publiquemos cosas divertidas pero verdaderas" en April Fools se está volviendo un poco viejo. Algo fresco y diferente es bienvenido aquí. - Jayron 32 13:00, 27 de febrero de 2018 (UTC)
- Si estoy leyendo esto correctamente, ¿la propuesta es esencialmente una nueva máscara que luego se habilita de forma predeterminada el 1 de abril? Incluso para ser considerado, necesitaría un nivel de pulido que podría no ser posible en solo un mes y medio, y definitivamente también necesitaría un gran botón de 'apagado' claramente visible para los usuarios. También hay un móvil en el que pensar, etc. - Insertar frase clave aquí ( o aquí ) 13:30, 27 de febrero de 2018 (UTC)
- No necesariamente una nueva máscara, sino el desarrollo de contenido derivado, dado el diseño de 40x24 y el enfoque de enlace numérico (Ceefax usó 100-999 mientras que prestel usó un rango de números de 32 bits IIRC. No estoy seguro de cómo se traducirían en wiki (título del artículo o id-hashes ¿tal vez?) 13:53, 27 de febrero de 2018 (UTC)
- Hay una fuente llamada Bedstead que emula la fuente de teletexto de estilo antiguo: http://bjh21.me.uk/bedstead/ , también hay algunos editores de marcos en línea, pero no estoy seguro de los detalles de la licencia. ShakespeareFan00 ( charla ) 13:53, 27 de febrero de 2018 (UTC)
- ¿Una fuente monoespaciada? - NaBUru38 ( charla ) 18:28, 27 de febrero de 2018 (UTC)
- La fuente es monoespaciada. pero ver a continuación 19:19, 27 de febrero de 2018 (UTC)
- ¿Una fuente monoespaciada? - NaBUru38 ( charla ) 18:28, 27 de febrero de 2018 (UTC)
- Hay una fuente llamada Bedstead que emula la fuente de teletexto de estilo antiguo: http://bjh21.me.uk/bedstead/ , también hay algunos editores de marcos en línea, pero no estoy seguro de los detalles de la licencia. ShakespeareFan00 ( charla ) 13:53, 27 de febrero de 2018 (UTC)
- Oponerse firmemente . Tomó años deshacerse de la idea de que Wikipedia debería celebrar el Día de los Inocentes y despedir a las personas "extrañas pero verdaderas" (excepto en DYK , donde todavía se aferran con tristeza ); no necesitamos otro grupo de comediantes autoproclamados. Wikipedia existe como un servicio para sus lectores, no para que sus editores se den una palmada en la espalda sobre quién puede ser el mayor sabelotodo. Aparte de cualquier otra cosa, si planea imponer un diseño de caracteres de 40X24, deberá persuadir a las personas que ejecutan todos los elementos existentes de la página principal para que se retiren; No puedo imaginar a alguien que haya pasado años mejorando un artículo con el estándar FA y que espera publicarlo el 1 de abril porque es un aniversario importante (y actualmente hay una acumulación de 6 artículos esperando para publicarse en esta fecha en Wikipedia: Es probable que los artículos destacados que no hayan estado en la conexión de página principal / fecha ) queden muy impresionados. - Iridiscente 18:38, 27 de febrero de 2018 (UTC)
- Esto no pretendía reemplazar la página principal actual del 1 de abril. Sería contenido paralelo. ShakespeareFan00 ( charla ) 19:13, 27 de febrero de 2018 (UTC)
- Esto parece una pérdida de tiempo. También lo que dijo Iri. TonyBallioni ( charla ) 19:15, 27 de febrero de 2018 (UTC)
- Parece que hay poco interés en esto, abandonado debido al razonamiento mencionado anteriormente. ShakespeareFan00 ( charla ) 19:19, 27 de febrero de 2018 (UTC)