stringtranslate.com

Wikipedia:Bomba de agua de pueblo (laboratorio de ideas)

Atajos
  • WP:VPI
  • WP:VPIL
La sección de laboratorio de ideas de Village Pump es un lugar donde se pueden incubar nuevas ideas o sugerencias sobre temas generales de Wikipedia, para luego enviarlas para un debate de consenso en Village Pump (propuestas) . Trate de ser creativo y positivo al comentar ideas.
Antes de crear una nueva sección, tenga en cuenta lo siguiente :

Antes de comentar, tenga en cuenta :

  • Esta página no es para sondeos de consenso . Los comentarios firmes de "En contra" y "A favor" generalmente no tienen cabida aquí. En cambio, se pueden debatir ideas y sugerir variaciones sobre ellas.
  • ¿Te preguntas si alguien ya tuvo esta idea? Busca en los archivos que aparecen a continuación y consulta Wikipedia:Propuestas perennes .

Las discusiones se archivan automáticamente después de permanecer inactivas durante dos semanas.

« Archivos , 40 , 41 , 42 , 43 , 44 , 45 , 46 , 47 , 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 58 , 59 , 60

Atajos de política para nombres completos en mayúsculas

En el espíritu de ensayos como WP:WTF? OMG! TMD TLA. ARG! y WP:ALPHABETTISPAGHETTI y WP:UPPERCASE , estoy tratando de usar muchas más letras minúsculas para nombrar todo cuando hago referencia a políticas como WP:OriginalResearch o wp:competenceisrequired . Personalmente, he descubierto que es menos probable que esto se asocie cognitivamente con gritar o abogar, se explica más por sí solo sin necesidad de pasar el mouse sobre el texto y es mucho más agradable a la vista. Espero que los editores más nuevos hayan sentido lo mismo.

Dos cosas que me gustaría abordar:

  1. No todas las subpolíticas tienen redirecciones tanto en minúsculas como en camelcase. Solo quiero asegurarme de que se puedan realizar sin controversias.
  2. En las páginas de políticas, los accesos directos a las subpolíticas siempre están en mayúsculas. Por lo tanto, tenemos (en RS) tanto WP:UBO como USEBYOTHERS como accesos directos en el cuadro, pero como solo UBO es un acrónimo, ¿por qué no podemos tener la segunda sugerencia de acceso directo como WP:UseByOthers ? (Similar en P&G). Es solo un indicador de que existen otros accesos directos además de MAYÚSCULAS.

Algo relativamente menor que no cambiará la funcionalidad real de nada. Solo reemplaza la ortografía sugerida del nombre completo (no las siglas) de los atajos de P&G de mayúsculas a camelcase. SamuelRiv ( discusión ) 19:26 19 sep 2024 (UTC) [ responder ]

Para adelantarme a la objeción de que los editores deberían enviar texto sin formato a P&G como se sugiere en los ensayos a los que hice referencia: estoy de acuerdo, eso es genial, si los editores realmente lo hicieran con cierta regularidad. Por mi parte, enviar texto sin formato es un poco más de escritura que puede no ser tan claro como para indicar que estoy haciendo referencia a P&G en la discusión en primer lugar, lo que a menudo es importante, ya que he descubierto que la gente rara vez hace clic en los enlaces de todos modos. SamuelRiv ( discusión ) 19:32 19 sep 2024 (UTC) [ responder ]
No creo que sea probable que recibas ninguna respuesta negativa sobre el punto 1. Durante mucho tiempo he tenido la costumbre de referirme a estas cosas en el caso que tenga más sentido en la oración que estoy escribiendo (normalmente en minúsculas o con la primera letra en mayúscula) y, si "mostrar vista previa" lo muestra como un enlace rojo, crea una redirección. No creo que nadie haya revertido esto nunca. Tendré que pensar un poco más sobre el punto 2: existe el peligro de que se hinche. Phil Bridger ( discusión ) 19:50 19 sep 2024 (UTC) [ responder ]
Para aclarar el punto n.° 2: en el cuadro del P&G que muestra los atajos en texto azul en negrita: uno es un acrónimo y el otro es el nombre completo, por lo que en mi ejemplo vinculado, el cuadro dice Shortcuts: WP:UBO WP:USEBYOTHERS . Sugiero reemplazar el atajo de nombre completo en el P&G de mayúsculas a mayúsculas y minúsculas, por lo que el cuadro ahora dice Shortcuts: WP:UBO WP:UseByOthers . No estoy seguro de dónde ves la hinchazón, ya que no se agrega ni se resta ni un solo byte, y funcionalmente no se cambia nada. SamuelRiv ( discusión ) 20:01, 19 de septiembre de 2024 (UTC) [ responder ]
Veo un posible punto de discordia: en muchas máscaras, incluida la versión vectorial heredada, la búsqueda incluye todas las redirecciones, y a algunos les puede molestar ver un montón de redirecciones que obstruyen preventivamente las sugerencias cuando quieren encontrar algo más después de escribir la primera palabra. Personalmente, me gustan mucho más las redirecciones de estilo punto 2. Aaron Liu ( discusión ) 23:29 19 sep 2024 (UTC) [ responder ]
¿La búsqueda de vectores heredados distingue entre mayúsculas y minúsculas? Entonces, si comienzo a buscar "ARNm", aparece una lista que incluye "ARNm", "ARNm", "ARNm", y todas ellas tienen enlaces a lo mismo. Si ese es el caso y alguien sigue usando ese software, entonces la adición o eliminación de redirecciones que distinguen entre mayúsculas y minúsculas seguramente ha dejado de ser una causa de dolor para esa persona hace mucho tiempo. SamuelRiv ( discusión ) 07:26 20 sep 2024 (UTC) [ responder ]
Hay muchas formas de buscar en Wikipedia, algunas de las cuales no distinguen entre mayúsculas y minúsculas y muestran una lista de resultados posibles a medida que escribes. Esto incluye el motor de búsqueda interno, que es independiente de la apariencia que uses (obtienes los mismos resultados en vector, vector legacy, monobook, etc.). Thryduulf ( discusión ) 11:29 20 sep 2024 (UTC) [ responder ]
No creo que el motor de búsqueda interno muestre varios resultados en la misma página debido a las redirecciones. Aaron Liu ( discusión ) 11:51 20 sep 2024 (UTC) [ responder ]
Eso tiene sentido. De todos modos, me gustan más las redirecciones de CamelCase porque queda muy claro dónde se separan las palabras. Aaron Liu ( discusión ) 11:52 20 sep 2024 (UTC) [ responder ]
¿Sabes qué separa las palabras con más claridad que CamelCase? Cualquier espacio. "Estás violando nuestra política sobre WP:BiographiesOfLivingPeople " frente a "Estás violando nuestra política sobre WP:biographies of living people ". También es más fácil de escribir; en su mayoría no necesita nuevas redirecciones; y se ve mucho menos raro para todos, excepto para los programadores. ( WP:biographiesoflivingpeople es incluso peor.) — Cryptic 12:37, 20 de septiembre de 2024 (UTC) [ responder ]
No soy partidario de redirecciones como esa y simplemente repito el título. El ejemplo de UseByOthers lleva a una sección con un nombre diferente. Aaron Liu ( discusión ) 12:45, 20 de septiembre de 2024 (UTC) [ responder ]
Como podría hacerlo WP:Use por otros . — Cryptic 12:55, 20 de septiembre de 2024 (UTC) [ responder ]
CamelCase requiere un poco menos de esfuerzo para escribir y aún así indica que el enlace es un acceso directo. Creo que la razón por la que todo está en mayúsculas es precisamente para diferenciarlos como redirecciones, y parte de esa diferenciación debería conservarse. Aaron Liu ( discusión ) 12:58, 20 de septiembre de 2024 (UTC) [ responder ]
Personalmente, no creo que el texto del enlace visible deba diferenciarse como redireccionamiento. Esto sirve principalmente para codificar un término (en mayúsculas o en mayúsculas) como jerga. Hay ocasiones en las que esto puede llevar a una mayor concisión, pero la mayoría de las veces la ganancia es pequeña, con el costo de una mayor confusión para aquellos que aún no conocen el título del destino y el texto correspondiente. Por ejemplo, a menudo los puntos de vista no neutrales se etiquetan como WP:NPOV. Valoro el punto de vista de que aprender la jerga de una comunidad es parte de unirse a esa comunidad. Sin embargo, creo que la Wikipedia en inglés ya tiene mucha jerga sin que todos los atajos se usen como jerga. isaacl ( discusión ) 15:55, 20 de septiembre de 2024 (UTC) [ responder ]
La razón por la que recomendaría el uso de camelcase como la segunda redirección sugerida (en el pequeño cuadro de redirecciones en las secciones de P&G), en lugar de las versiones en prosa espaciada (que también me gustaría que los editores usaran más), es que camelcase también sugiere al menos un poco que hay un acrónimo que la gente usa, o es decir, que un novato que siga una discusión podría deducir más fácilmente 'WP:UseByOthers ↔ WP:UBO'. Si todos aquí prefieren incluir 'WP:Use by others', me parece bien; también se podrían poner tres atajos en lugar de solo dos: 'WP:UBO WP:UseByOthers WP:Use by others'. SamuelRiv ( discusión ) 17:38, 20 de septiembre de 2024 (UTC) [ responder ]
Además, deletrear las abreviaturas puede dar al menos una pista de lo que significa la jerga. Aaron Liu ( discusión ) 21:41 27 sep 2024 (UTC) [ responder ]
@ SamuelRiv , si quieres que esto sea un poco más fácil, intenta cambiar de "Fuente" a "Visual" en la herramienta de respuesta durante unos días.
Utilice su herramienta de enlace para agregar enlaces. En el modo visual, simplemente escriba [[y notará que desea crear un enlace y abrirá la herramienta para usted (alternativamente, haga clic en el botón en la barra de herramientas o use el atajo de teclado (=⌘K en una Mac). Escriba el atajo (por ejemplo, WP:CORP) en el cuadro de búsqueda de enlaces y le ofrecerá un enlace al título completo (por ejemplo, Wikipedia:Notability (organizaciones y empresas) . Para secciones individuales, abra la página en una pestaña y pegue la URL completa en su comentario. Por ejemplo, abrí WP:SIRS en otra pestaña y pegar la URL completa me da un enlace bien formateado a Wikipedia:Notability (organizaciones y empresas) #Cómo aplicar los criterios .
Te sugiero que pruebes esto durante unos días y veas si te gusta. WhatamIdoing ( discusión ) 06:14 25 sep 2024 (UTC) [ responder ]
@ WhatamIdoing La herramienta de enlace del modo fuente en la barra de herramientas hace lo mismo. Aaron Liu ( discusión ) 21:40, 27 de septiembre de 2024 (UTC) [ responder ]
La [[secuencia solo funciona en modo visual. WhatamIdoing ( discusión ) 22:03 27 sep 2024 (UTC) [ responder ]
Sí, pero el icono de enlace en la barra de herramientas funciona de la misma manera. (Además, ConvenientDiscussions tiene una ventana emergente que ayuda a escribir enlaces en línea y que se completa automáticamente, aunque no expande automáticamente la redirección). Aaron Liu ( discusión ) 04:17, 28 de septiembre de 2024 (UTC) [ responder ]
Si vamos a continuar publicitando estos accesos directos en los cuadros {{ sh }} , estoy seguro de que será lo suficientemente visible como para requerir una solicitud de comentarios, o al menos una {{ discusión centralizada }} . Aaron Liu ( discusión ) 23:27 28 sep 2024 (UTC) [ responder ]

¡Insignia verificada para administradores!

No estoy seguro de lo que otros pensarán de esto, pero accidentalmente tuve esta idea: ¿cómo sería si añadiéramos una insignia verificada, similar a las insignias verificadas de Instagram o Facebook, a las firmas de los administradores cuando comentan? Sería más fácil identificar que el editor es un administrador, en lugar de tener que comprobar su perfil, contribuciones o diferencias, que es un proceso largo y no ideal. Similar a cómo los grupos de Discord usan un nombre verde para los administradores. ¿Qué opinas de esto? Grab Up - Talk 13:03, 22 de septiembre de 2024 (UTC) [ responder ]

@ GrabUp , hay un script para eso: Usuario:Mdaniels5757/markAdmins . Schazjmd  (discusión) 13:46, 22 de septiembre de 2024 (UTC) [ responder ]
Schazjmd , GrabUp : hay bastantes , en realidad. —  ClaudineChionh ( ella/ella · discusión · contribuciones · correo electrónico ) 13:47 22 sep 2024 (UTC)[ responder ]
Mi favorito personal es user:Bugghost/Scripts/UserRoleIndicator . Aaron Liu ( discusión ) 15:30 22 sep 2024 (UTC) [ responder ]
Los administradores que quieran hacerlo pueden hacerlo, y los usuarios que quieran verlo también pueden hacerlo. Pero, en general, esto no tiene por qué ser ni debería ser la opción predeterminada. Todos hemos visto cómo, a veces, los editores parecen mostrar una deferencia inusual hacia los administradores conocidos en discusiones sobre asuntos no relacionados con la administración, como el contenido y el metacontenido. Esto puede ser inconsciente o consciente, pero es contraproducente para la discusión y contrario al espíritu del proyecto de cualquier manera. SamuelRiv ( discusión ) 14:14, 22 de septiembre de 2024 (UTC) [ responder ]
Estoy de acuerdo con esto. Los administradores son solo usuarios a los que se les confía cierta información , no tienen ninguna autoridad especial sobre el contenido ni nada más. Chaotic Enby ( discusión · contribuciones ) 19:26, 22 de septiembre de 2024 (UTC) [ responder ]
Si utilizo mis herramientas de administrador para bloquear a un editor o eliminar una página o proteger o desproteger un artículo, cualquiera que esté mirando de cerca sabrá que soy un administrador porque solo los administradores pueden hacer esas cosas. Por otro lado, cuando escribo un artículo nuevo o amplío un artículo existente o hago una evaluación en la página de discusión de un artículo u ofrezco consejos en la Casa de Té, nadie necesita saber que soy un administrador porque esas no son funciones administrativas y solo soy otro editor en ese momento. Hice todas esas cosas mucho antes de convertirme en administrador. Si le digo a otro editor que soy un administrador, eso es en el contexto de una advertencia. No veo ningún beneficio en una insignia. Cullen328 ( discusión ) 08:52, 24 de septiembre de 2024 (UTC) [ responder ]
De todos modos, es técnicamente imposible aplicarlo con discusiones tradicionales en wikitexto. Las discusiones estructuradas como las que se usan en otras wikis podrían ser compatibles, pero en ese caso, ¿por qué se les da la marca azul a los administradores y no a los demás usuarios? -- Jasper Deng (discusión) 09:00, 24 de septiembre de 2024 (UTC) [ responder ]
(En realidad es posible, simplemente consulta a los miembros de una clase CSS y muéstralos de la misma manera que lo harías en discusiones estructuradas). Aaron Liu ( discusión ) 10:57, 24 de septiembre de 2024 (UTC) [ responder ]
(Eso no es a prueba de suplantación de identidad).-- Jasper Deng (discusión) 11:03 24 sep 2024 (UTC) [ responder ]
¿Sí lo es? La API siempre dice la verdad. Por clase CSS de consulta me refiero a todos los enlaces de páginas de usuario junto con las marcas de tiempo. Hay scripts anteriores que hacen exactamente lo mismo.
Una implementación más eficiente sería agregar automáticamente una nueva clase CSS a los enlaces de páginas de usuario de administración junto con la desinfección de firmas contra la adición manual de la clase. Dicho esto, no estoy convencido de que esto sea algo que debamos hacer. Aaron Liu ( discusión ) 12:48, 24 de septiembre de 2024 (UTC) [ responder ]
No creo que esto sea algo que debamos hacer (si los usuarios realmente lo quieren, ya hay varios scripts de usuario que lo hacen y permiten CSS personalizados). Yo diría que el único lugar donde no es a prueba de suplantación es si alguien se esfuerza por falsificar la firma de otro usuario, pero en este punto solo está diciendo que nuestras firmas en sí mismas no son a prueba de suplantación, y una verificación rápida en el historial de la página es suficiente para detectarlo y revertirlo... Chaotic Enby ( discusión · contribs ) 14:02, 24 de septiembre de 2024 (UTC) [ responder ]
No, no lo es. El usuario puede falsificar completamente la insignia visualmente sin siquiera consultar la API, ya que los estilos en línea son posibles en el wikitexto y los usuarios controlan sus propias firmas. -- Jasper Deng (discusión) 18:51 24 sep 2024 (UTC) [ responder ]
Es un buen punto. Si nos decidimos por un estilo basado en API que cambiara los signos para decir algo como " Jdforrester ( discusión ) es un administrador ", entonces, poco después, encontraríamos que algunos editores habían configurado un WP:CUSTOMSIG para decir algo como " WhatamIdoing ( discusión ) es un administrador ", solo que el primero es "real" y está basado en API, y el segundo es imitado en el wikitexto.
Podría ser posible minimizar esto tecnológicamente, utilizando el mismo tipo de código que ya no permite firmas personalizadas sin un enlace a su propia cuenta, pero hacer eso requeriría la intervención de los desarrolladores, lo que a su vez probablemente tenga un requisito mínimo de que pensemos que es una buena idea, lo que no parece ser el caso. WhatamIdoing ( discusión ) 06:25, 25 de septiembre de 2024 (UTC) [ responder ]

Medidas propuestas para mitigar el vandalismo en la región india

En la actualidad, Wikipedia aborda el vandalismo en la India mediante bloqueos de IP y host. Sin embargo, un problema importante es que la mayoría de los indios acceden a Internet a través de conexiones móviles, donde los proveedores de telefonía móvil asignan IP NAT. Como resultado, cuando los administradores bloquean un rango de host, afectan inadvertidamente a una gran parte de los usuarios móviles. En consecuencia, las personas dentro de estos rangos no pueden crear cuentas ni realizar modificaciones de IP. Ha habido informes de una disminución de editores de la India, que coincidió con el cambio hacia el acceso a Internet a través de dispositivos móviles.

Para abordar este desafío, propongo introducir un requisito para que los usuarios que accedan a Wikipedia desde redes sospechosas proporcionen una dirección de correo electrónico verificada al crear una cuenta. El correo electrónico debe proceder de un dominio confiable, como Gmail o Outlook, que requieren la verificación del número de teléfono móvil como parte del proceso de registro. Esto ayudaría a garantizar que las nuevas cuentas de estas redes sean legítimas.

Además, hay margen para mejorar la forma en que Wikipedia gestiona los actos de vandalismo reincidentes. Actualmente, cuando un usuario es denunciado por vandalismo, recibe un bloqueo temporal, pero una vez que el bloqueo expira, su cuenta vuelve a su estado anterior sin mayores consecuencias. Se ha observado que algunos usuarios se aprovechan de esto haciendo ediciones constructivas durante un tiempo, solo para volver a cometer actos de vandalismo más tarde, perpetuando así un ciclo de prohibiciones temporales. Con el tiempo, ciertos usuarios han acumulado un número considerable de ediciones y un estatus considerable, que aprovechan para manipular datos factuales (como cifras de taquilla) o priorizar ciertas fuentes para sesgar las clasificaciones. El alto número de ediciones a menudo desalienta a otros editores a denunciarlos, a pesar de su historial de comportamiento disruptivo.

Para frenar esto, sugiero implementar medidas adicionales al reactivar usuarios después de un bloqueo. En primer lugar, se debería exigir a los usuarios que proporcionen una dirección de correo electrónico verificada de un dominio confiable antes de que se reactive su cuenta. En segundo lugar, se los debería reactivar en un modo limitado o "seguro", recuperando los privilegios de edición completos solo después de completar una cantidad específica de ediciones de buena fe. Esto frenaría a los vándalos organizados y alteraría su ritmo, ya que muchos parecen operar según un cronograma cuidadosamente coordinado.

Por último, para proteger aún más la plataforma, las ediciones de IP de dominios sospechosos deben bloquearse permanentemente, ya que a menudo se utilizan para abusos repetidos. W170924 ( discusión ) 21:50 23 sep 2024 (UTC)[ responder ]

Adición Para abordar el problema del vandalismo no denunciado, que a menudo queda solo como una descripción de edición, sugiero implementar un filtro de bloqueo de correo electrónico obligatorio (ERBF) para moderadores. Esta herramienta permitiría a los moderadores congelar temporalmente una cuenta de usuario hasta que el usuario proporcione una dirección de correo electrónico válida de dominios confiables como Google o Outlook, que requieren la verificación del número de teléfono en India para la activación de la cuenta. Además, el usuario no debería poder cambiar la dirección de correo electrónico durante un mes.

Además , los usuarios que hayan sido bloqueados temporalmente por vandalismo deberían ser reincorporados en "modo seguro", lo que significa que solo tendrán los permisos de una cuenta recién creada. En este modo, deben completar 100 ediciones para recuperar su estado anterior. Si el usuario es bloqueado nuevamente por un comportamiento similar, la cantidad requerida de ediciones podría duplicarse para las reincorporaciones posteriores. Este enfoque fomenta la edición responsable y, al mismo tiempo, proporciona a los moderadores herramientas más efectivas para evitar interrupciones repetidas. W170924 ( discusión ) 07:21 24 sep 2024 (UTC) [ responder ]

Eliminé las declaraciones que no se pudieron implementar debido a los principios básicos de WMF, pero estoy seguro de que la última parte no viola ninguna privacidad. W170924 ( discusión ) 23:55 24 sep 2024 (UTC) [ responder ]

Un pequeño detalle: ni Gmail ni Outlook requieren la verificación del número de móvil para crear una cuenta de correo electrónico. Schazjmd  (discusión) 21:56 23 sep 2024 (UTC) [ responder ]
@ Schazjmd : No estoy seguro de otras regiones, pero en India no permitirán el acceso a su servicio hasta que se complete la verificación del número de teléfono. W170924 ( discusión ) 22:04 23 sep 2024 (UTC) [ responder ]
No lo sabía, @W170924, ¡gracias! En los EE. UU., no existe ningún requisito de verificación telefónica para configurar una dirección de correo electrónico. Schazjmd  (discusión) 22:07 23 sep 2024 (UTC) [ responder ]
Preferiría que simplemente hagamos que las cuentas con un número de teléfono verificado estén exentas del bloqueo de IP de forma predeterminada, a menos que el bloqueo de rango solicite específicamente bloquearlas también. Sin embargo, el software de Wikipedia aún no tiene esa funcionalidad.

Ediciones de IP de dominios sospechosos

¿Qué significa eso, jajaja? Aaron Liu ( discusión ) 23:23 23 sep 2024 (UTC) [ responder ]
@ Aaron Liu : escribí "ediciones de IP de dominios sospechosos", aunque quise decir "ediciones de IP de rangos de IP sospechosos", lo cual fue un error involuntario. Usar un número de teléfono verificado es una buena práctica, pero aumentaría significativamente los costos para Wikipedia. W170924 ( discusión ) 04:22 24 sep 2024 (UTC) [ responder ]
Actualmente, cuando un usuario es marcado por vandalismo, recibe un bloqueo temporal, pero una vez que el bloqueo expira, su cuenta se restaura a su estado anterior sin mayores consecuencias. Se ha observado que algunos usuarios se aprovechan de esto al realizar modificaciones constructivas durante un período, solo para volver a cometer vandalismo más tarde, perpetuando un ciclo de prohibiciones temporales.
Se necesita citar este punto. El vandalismo reiterado casi siempre se responde con bloqueos cada vez mayores para los usuarios registrados, y el tercer o cuarto bloqueo suele ser indefinido. En el caso de las direcciones IP, los bloqueos suelen ser temporales (aunque su duración aumenta) en lugar de indefinidos, ya que suelen reasignarse a nuevos usuarios no relacionados. Casi todas las direcciones IP bloqueadas indefinidamente son servidores proxy abiertos en lugar de direcciones IP personales.
Con el tiempo, ciertos usuarios han acumulado cantidades considerables de ediciones y estados, que aprovechan para manipular datos factuales (como cifras de taquilla) o priorizar ciertas fuentes para sesgar las clasificaciones.
De nuevo, ¿tienes alguna evidencia? Un usuario con bloqueos temporales repetidos no tendría mucho "estatus", sea lo que sea que eso signifique, y los cambios no son confiables en función de la reputación del usuario que los realiza, sino de la calidad de su origen. Chaotic Enby ( discusión · contribs ) 23:52 23 sep 2024 (UTC) [ responder ]
@ Chaotic Enby : Reconoces que una prohibición permanente solo se impone después del tercer bloqueo. Esto significa que una persona puede crear una cuenta, cometer actos de vandalismo, recibir un bloqueo temporal y luego contribuir positivamente durante un año antes de repetir el comportamiento. Básicamente, al usuario se le dan tres oportunidades para participar en tales acciones, y su historial de edición permanece intacto durante todo el proceso. Este proceso se puede prolongar, ya que la mayoría de los actos de vandalismo solo dan como resultado una advertencia. Recientemente, ha habido un enfoque más indulgente con el vandalismo, como el uso de fuentes poco confiables para citar información o la edición de un rango sin proporcionar las referencias adecuadas. En algunos casos, el comportamiento del usuario puede pasar completamente desapercibido. Mi intención no era señalar a individuos en particular, sino resaltar este problema en curso. Creo que el vandalismo sistemático requiere un enfoque sistemático. Además, para un usuario nuevo, el recuento de ediciones importa, ya que es posible que aún no esté familiarizado con el funcionamiento de Wikipedia. W170924 ( discusión ) 04:43, 24 de septiembre de 2024 (UTC) [ responder ]
Entonces, ¿un editor "contribuirá positivamente durante un año" y luego se involucrará en ediciones sistemáticas de mala fe (sin importar cuántas semanas o meses pueda llevar discernir esto, es una función que se escala con la cantidad de ediciones de mala fe en el espacio de artículos)? Me hago eco de los usuarios anteriores al pedir ejemplos en los que esto sucede sistemáticamente, porque... si la gente está editando WP positivamente durante un año entero solo para jugar con el sistema más tarde, plantearía la hipótesis (a la espera de ejemplos) de que WP sale ganando. SamuelRiv ( discusión ) 06:10, 24 de septiembre de 2024 (UTC) [ responder ]
@SamuelRiv : Sigo reiterando que el alcance no es nombrar a nadie, pero puedes consultar mi historial.W170924 ( discusión ) 07:23, 24 de septiembre de 2024 (UTC) [ responder ]
@ Jasper Deng : Te envié mis comentarios sobre esto. ¿Crees que mis ideas son erróneas? W170924 ( discusión ) 13:37 24 sep 2024 (UTC) [ responder ]
Para contextualizar, enviaron un correo electrónico. Aaron Liu ( discusión ) 14:19 24 sep 2024 (UTC) [ responder ]
@W170924: Por favor, no me envíes correos electrónicos a menos que sea absolutamente necesario que mantengas la privacidad, lo cual no ocurre aquí. Lo que me enviaste demuestra que no entiendes qué es el vandalismo ; lee WP:NOTVAND . Tus sugerencias tampoco ayudarían en los casos en los que se pasa por alto un vandalismo sutil. -- Jasper Deng (discusión) 19:57 24 sep 2024 (UTC) [ responder ]
@ Jasper Deng : Entonces, ¿eso significa que las personas pueden hacerlo si no se alcanza el umbral? W170924 ( discusión ) 22:19, 24 de septiembre de 2024 (UTC) [ responder ]
@W170924: No entiendo tu pregunta. No toda alteración es vandalismo. -- Jasper Deng (discusión) 04:14 25 sep 2024 (UTC) [ responder ]
Ok.W170924 ( discusión ) 06:08 25 sep 2024 (UTC) [ responder ]
@ Cabayi : Sería inapropiado que yo comentara el ejemplo, ya que soy muy parcial por ser indio. Solo diré esto: si el asunto se agrava, Wikipedia puede perder a todos los editores indios en el proceso. W170924 ( discusión ) 13:37 24 sep 2024 (UTC) [ responder ]
Por eso no se debería exigir a los editores que envíen información personal identificable: nadie debería ser procesado. Aaron Liu ( discusión ) 14:20 24 sep 2024 (UTC) [ responder ]

Hacer ping a SGrabarczuk para hablar sobre m:Trust and Safety Product/Temporary Accounts, lo que podría reducir este problema de nuestra parte. En el caso improbable de que algún ISP afectado vea esto, si quisiera reducir este problema por sí mismo, entonces cambiar de usar CGNAT rotando una pequeña cantidad de direcciones IPv4 a usar una cantidad mayor y estable de direcciones IPv6 sería de gran ayuda, y eso es algo que podrían hacer ellos mismos. WhatamIdoing ( discusión ) 06:31 25 sep 2024 (UTC) [ responder ]

@ WhatamIdoing : Como muestra mi ejemplo de Jio, el mero uso de IPv6 no es suficiente por sí solo. Las subredes aún tienen que estar localizadas geográficamente, sin realizar asignaciones desde un bloque gigante, o de lo contrario los mismos abusadores terminan saltando rangos extremadamente amplios, lo que he observado mientras realizaba el trabajo de CheckUser. -- Jasper Deng (discusión) 06:35, 25 de septiembre de 2024 (UTC) [ responder ]

Corrija Draftification con una nueva plantilla

La draftificación ha sido criticada durante mucho tiempo como una puerta trasera para la eliminación. En New Pages Patrol (NPP), es común mover nuevos artículos que no están listos para el espacio principal al espacio de borradores. De esta manera, se conservan los artículos que podrían ser aptos para Wikipedia, pero que aún no lo son. El creador del artículo tiene entonces la oportunidad de mejorar su artículo sin que los NPPers le respiren en la nuca o que lo lleven a Artículos para eliminación . Si alguien, incluido el creador del artículo, se opone a la draftificación, el artículo debe ser devuelto al espacio principal (la draftificación debe revertirse). Esto se explica en DRAFTNO #6 y #7 . No se requiere ninguna razón para la objeción.

Problema: Sin embargo, también tenemos una regla según la cual los borradores que no se han editado durante seis meses se eliminan automáticamente, según el Criterio para la eliminación rápida G13 . Por lo tanto, los New Page Patrollers bien intencionados redactarán unilateralmente nuevos artículos que aún no están listos para la enciclopedia. Los nuevos editores que crearon el artículo pueden estar en desacuerdo con la medida, sin saber que pueden objetar. Los nuevos usuarios pueden desanimarse y abandonar Wikipedia por completo, y después de seis meses el borrador se elimina según el Criterio para la eliminación rápida G13. Como este proceso ocurre sin debates de la comunidad, el resultado es que la redacción se denomina "puerta trasera a la eliminación".

Solución: Este problema se puede resolver sin cambiar la política o la práctica actual . Solo necesitamos hacer que sea muy obvio para los nuevos usuarios que pueden objetar la conversión en borrador. También podemos hacer que sea fácil revertir la conversión en borrador (asumiendo que el nuevo usuario está autoconfirmado ). Sugiero que hagamos esto agregando una plantilla a todos los artículos que se convierten en borradores . La plantilla incluiría un gran botón azul , similar al botón "¡Enviar el borrador para revisión!" en Template:AfC submission/draft , que dice "Objetar este movimiento". Al hacer clic en este botón: 1. Deja un mensaje en la página de discusión del editor que realizó la conversión en borrador, notificándole que ha habido una objeción al movimiento y solicitando que se revierta inmediatamente. 2. Mueve la página de regreso al espacio principal automáticamente, o si la cuenta del editor no puede realizar esta tarea, crea una entrada en Movimientos solicitados/Movimientos técnicos a tal efecto. Esto último es mejor, pero también más complejo técnicamente. También sería útil agregar un botón similar a Template:Uw-articletodraft , la advertencia que normalmente aparece durante la redacción del borrador.

Implementación: Una vez que la nueva plantilla esté lista, se puede agregar al script de usuario MoveToDraft de MPGuy , que es la forma más común en que los miembros de NPP redactan borradores de artículos. Debe colocarse sobre la plantilla AfC en todos los borradores de artículos.

Agradecería los comentarios de editores con habilidades técnicas que puedan crear esta plantilla (o decirme que es imposible), de personas que redactan artículos y de editores no involucrados que tengan opiniones sobre el proceso de redacción. Toadspike [Discusión] 10:37 26 sep 2024 (UTC) [ responder ]

Esta idea no es realmente mía, obviamente surgió a raíz de la convocatoria de propuestas más reciente. Una idea similar se discutió anteriormente aquí , pero esa discusión propuso un requisito que todos los editores deben seguir (política), no una solución técnica, y terminó en un desastre. Para evitar algo similar, pido a todos los participantes que se concentren en mejorar la situación actual en lugar de debatir la moralidad de la redacción de borradores en su conjunto. Toadspike [Discusión] 11:03, 26 de septiembre de 2024 (UTC) [ responder ]
Notificar a los usuarios que comentaron más directamente sobre este tema en la RfA: @ Alalch E. @ Usuario:Onel5969 @ Usuario:Hobit @ Usuario:Fangz @ Usuario:Nsk92 . También notifiqué a la página de discusión de NPP y publiqué un mensaje en Discord. No estoy seguro de cómo notificar a todos los participantes de la discusión anterior (aparte de hacerlo manualmente) y no estoy seguro de que sea productivo considerando cuántas personas estuvieron involucradas y cuán fuera de tema se volvió, así que no lo haré por ahora. Toadspike [Discusión] 11:07 26 sep 2024 (UTC) [ responder ]
¿Estás seguro de que quieres convertir esto en una RfC? ¿Hay un ANTES en alguna parte? Aaron Liu ( discusión ) 11:32 26 sep 2024 (UTC) [ responder ]
Buen punto, no estoy seguro de si la etiqueta RfC se aplica, así que eliminaré las plantillas. Estaba buscando formas de notificar a las personas y leí mal RFCBEFORE. Toadspike [Discusión] 11:34, 26 de septiembre de 2024 (UTC) [ responder ]
No me gusta la idea de un botón, pero creo que se debería cambiar la plantilla. Creo que tener un botón sugiere que es una opción predeterminada, pero creo que un enlace está bien. Fangz ( discusión ) 12:37 26 sep 2024 (UTC) [ responder ]
Si un nuevo editor cree que su artículo está listo para el espacio principal, lo colocará allí. También estará encantado de revertir la decisión. Si un nuevo editor no está seguro, probablemente pedirá ayuda primero o utilizará el espacio de borradores. Cremastra ( discusión ) 19:35 26 sep 2024 (UTC) [ responder ]
Creo que la preocupación expresada por Joe y otros que apoyan la teoría de la "puerta trasera" es que los nuevos usuarios no saben cómo revertir el traslado a Draftspace. ¿No estás de acuerdo con esa suposición? Toadspike [Discusión] 19:53, 26 de septiembre de 2024 (UTC) [ responder ]
Creo que la mayoría de los usuarios no saben cómo revertir el cambio, sí. También creo que no deberíamos entregárselo en bandeja de plata, porque eso probablemente anule en gran medida el objetivo de la draftificación. ¿Cuál es la solución a esto? No podría decirte. Cremastra ( discusión ) 20:09 26 sep 2024 (UTC) [ responder ]
¿El objetivo de la elaboración de borradores es hacer que mi visión del valor del tema sea más poderosa que la de los novatos? La seguridad a través de la oscuridad funciona para eso, pero no de manera confiable. WhatamIdoing ( discusión ) 20:22 26 sep 2024 (UTC) [ responder ]
Tal vez no sepan cómo hacerlo, pero lo que es más importante, no saben que se les permite hacerlo. Tenemos que recordar lo inusual que es nuestro proceso colaborativo . Si un editor inexperto contribuye con un artículo a Wikipedia y luego lo despublican rápidamente con un mensaje que dice que hay algo incorrecto en él, no pensarán: "Hmm, no estoy seguro de estar de acuerdo con eso, voy a revertirlo y/o discutirlo con mis colegas editores para encontrar un consenso". Pensarán que alguien con la autoridad para decidir qué sucede con los artículos ha rechazado mi contribución y que soy un simple novato. En ese punto, o bien se darán por vencidos (la mayoría) o perseverarán y entrarán en un ciclo de intentar satisfacer primero al revisor de NPP y luego a una sucesión de revisores de AfC hasta que finalmente se den por vencidos o logren escribir una GA, que parece ser aproximadamente el estándar que AfC está aplicando estos días. Incluso los editores con mucha experiencia caen en esta trampa porque, aunque los mensajes con plantillas intentan comunicar la gama completa de opciones que tiene el usuario (ahora al menos, después de que yo y otros hemos pasado varios años luchando por ello), es realmente difícil comunicar que todos somos iguales y todos tenemos voz aquí dentro de una estructura de borrador-revisión que implícitamente eleva las opiniones de los revisores sobre los demás. –  Joe  ( discusión ) 07:31, 27 de septiembre de 2024 (UTC) [ responder ]
He extraído los 10 artículos más recientes que se trasladaron al espacio principal con el script AFCH. Son los siguientes:
Eso es un promedio de 372,5 palabras y 12,6 referencias. El artículo promedio tiene 338 palabras y 4 referencias. En comparación con los artículos existentes, el 53 % de nuestros artículos existentes tienen menos de 372,5 palabras y el 83 % tiene menos de 12,6 referencias. Uno de cada seis artículos tiene menos palabras que el más corto de esta lista. Uno de cada tres artículos es más corto que el segundo más corto de esta lista.
Creo que estos números dejan claro que la AFC espera más referencias que las que se encuentran en la práctica comunitaria actual, y que están tratando de aceptar solo artículos que sean tan largos como aquellos en los que los editores han estado trabajando en el espacio principal durante años.
Por cierto, durante el mismo período de tiempo, se eliminaron más de 100 páginas del espacio de nombres Draft:. No deberías asumir que esto significa que se eliminan más del 90% de los borradores, porque las eliminaciones son intermitentes y este es un tamaño de muestra relativamente pequeño, pero eso es más o menos lo que esperaba. WhatamIdoing ( discusión ) 20:56 27 sep 2024 (UTC) [ responder ]
Dado que la plantilla de borrador predeterminada del NPP se cambió a Template:Draft article un día antes de que comenzara esta discusión, creo que mi propuesta es discutible. No veo cómo podríamos mejorar mucho esa plantilla, pero puedo plantear algunos cambios menores de redacción en la Template Talk. Si alguien quiere cerrar esta discusión, está bien; si otros desean continuar discutiendo otras cosas aquí, les deseo lo mejor. Toadspike [Discusión] 21:16 27 sep 2024 (UTC) [ responder ]
También vale la pena hablar de la notificación de usertalk que deja MTD, que solo ofrece una opción: enviar para revisión. En principio, estamos de acuerdo en que no deberíamos engañar a la gente para que piense que la redacción de borradores o la revisión de contenido son obligatorias para un creador de artículos típico.Las rododendritas hablan\\ 13:29, 28 de septiembre de 2024 (UTC) [ responder ]
Creo que esto ilustra algunos de los malentendidos que cometen las personas a las que no les gusta la elaboración de borradores. Observas la lista proporcionada y piensas: "Vaya, muchas referencias, la mayoría no son borradores ni microborradores, ¿por qué diablos se han elaborado?". Yo mismo lo hice, preguntándome si las 10 fueron realizadas por un solo editor, que tal vez no tenía un conocimiento sólido de la elaboración de borradores. Pero luego te sumerges en los méritos de las fuentes o en los problemas de la UPE, y parece que las 8 elaboraciones de borradores parecen justificadas. Onel 5969 TT me 20:32, 29 de septiembre de 2024 (UTC) [ responder ]
@ Onel5969 , me pregunto si podrías explicar un poco mejor "el periódico" en el artículo 9. Dices que el artículo tiene "cero fuentes independientes confiables", pero los periódicos impresos tradicionales son fuentes independientes confiables. Luego dices que no tiene un número de página, pero el enlace te lleva directamente a una copia escaneada de la página correcta; el artículo citado [título dado en la cita] está en las últimas dos columnas. Nada de eso hace que el periódico sea menos independiente. ¿Te preocupa que el artículo parezca ser anterior al uso del nombre en el título del artículo ("De Zanbak" significa "El arenero")? WhatamIdoing ( discusión ) 20:51 29 sep 2024 (UTC) [ responder ]
Podría ser la traducción, pero no parece haber nada que conecte al grupo mencionado en ese artículo con De Zanbak. Pero incluso si lo hubiera, agf, esa sigue siendo la única fuente independiente y exhaustiva. Onel 5969 TT me 01:15, 30 de septiembre de 2024 (UTC) [ responder ]
Me alegra que estemos de acuerdo en que un periódico es una fuente independiente. WhatamIdoing ( discusión ) 01:20 30 sep 2024 (UTC) [ responder ]
Si un nuevo editor incluye 5 fuentes en su artículo y lo trasladan a [un lugar que no puse] porque "se necesitan más fuentes" o "no hay fuentes", ¿cuántos de ellos se tomarán el tiempo de aprender que el editor experimentado en realidad quiso decir que ninguna de estas fuentes contiene lo que creo que es una cobertura significativa y profunda en fuentes independientes confiables y luego tendrán la confianza de decir "en realidad, esta persona experimentada con el poder de eliminar mi artículo de Wikipedia está equivocada y yo tengo razón, aprenderé a desafiarlos y cómo y dónde expresar mi punto de vista de una manera que las personas poderosas me escuchen" en lugar de simplemente rendirse en algún punto de ese camino? Y antes de que alguien lo diga, no, el hecho de que algunos editores de mala fe puedan estar entre los disuadidos no justifica la pérdida de editores de buena fe. Thryduulf ( discusión ) 21:29, 29 de septiembre de 2024 (UTC) [ responder ]
Supongo que esa es la diferencia entre los editores que se preocupan por la calidad en WP y los que se preocupan por la cantidad. Pero por eso dije que la justificación dada podría haber sido mejor. Onel 5969 TT me 01:17, 30 de septiembre de 2024 (UTC) [ responder ]
¿Es realmente una cuestión de calidad versus cantidad?
¿O es esta la diferencia entre editores que prefieren ver una página publicada en Wikipedia:Artículos para su eliminación o Wikipedia:Fusiones de artículos propuestas en lugar de ocultarla unilateralmente hasta que se elimine sin el nivel de supervisión de la comunidad que esperamos de la AFD? Por ejemplo, no estoy convencido de que "De Zanbak" sea un tema viable para un artículo, pero creo que hay varias formas de abordar esa preocupación, y no creo que el espacio Borrador: ayude. De hecho, lo único que hace que mover esa página al espacio Borrador: sea diferente a moverla al espacio Usuario: es que es mucho más probable que se elimine durante el próximo año si está en el espacio Borrador: que si está en el espacio Usuario:. WhatamIdoing ( discusión ) 01:26, 30 de septiembre de 2024 (UTC) [ responder ]
Bueno, dado que la redacción de borradores no es una "puerta trasera para borrar", ni es "ocultar un artículo", es definitivamente una cuestión de calidad versus cantidad. La redacción de borradores, en resumen, es una medida de control de calidad. Se trata de artículos que pueden ser lo suficientemente notables para el espacio principal, pero simplemente no están en condiciones suficientes para estar allí. Pero, como otros vehículos en WP, los editores de buena fe pueden estar en desacuerdo sobre la notoriedad de un artículo, por lo que, por ejemplo, en el artículo de De Zandbak, Jay8g (que lo etiquetó para notoriedad) y Jonathan Deamer (que lo redactó) pueden considerarlo potencialmente notable, mientras que tú, WhatamIdoing, podrías simplemente haberlo enviado a AfD, porque no lo consideras notable. Pero eso no significa que el sistema no esté funcionando. Tal vez podamos ajustar la redacción actual en la plantilla para incluir dónde se pueden agregar recursos sobre dónde un editor puede pedir ayuda (por ejemplo, AFC o Teahouse). Onel 5969 TT me 09:20 30 septiembre 2024 (UTC) [ responder ]
Bueno, dado que la redacción de borradores no es una "puerta trasera para la eliminación" ni tampoco es "ocultar un artículo", dices eso como si no hubiera forma posible de que editores de buena fe pudieran estar en desacuerdo, pero eso simplemente no es cierto. Si alguna de esas cosas es cierta es una cuestión de opinión (y, en mi opinión, una que es consistente con la evidencia presentada). Thryduulf ( discusión ) 10:07 30 sep 2024 (UTC) [ responder ]
Hola. No, los editores pueden tener diferentes interpretaciones y estar en desacuerdo sobre ciertos temas. Sin embargo, en este caso, no se trata de un desacuerdo. Mantener esos puntos de vista indica una falta de comprensión de lo que es el proceso de elaboración de borradores. Eso no es lo que es la elaboración de borradores, es, como he dicho, simplemente una medida de control de calidad. Sería como decir que es una cuestión de opinión si esta persona escribió o no un artículo sobre sí misma, eso puede interpretarse como que no es una edición de COI. O si un artículo simplemente copia y pega la información de la Enciclopedia Británica, no puedes decir que es tu opinión que eso no es una copia. Quiero decir, tengo el máximo respeto por ti, Thryduulf, y haces un gran trabajo en WP. Hay cosas en WP que son subjetivas (por ejemplo, qué constituye exactamente SIGCOV), mientras que otras son objetivas (por ejemplo, la edición de UPE/COI, la copia). Lo que es la elaboración de borradores cae en la última categoría. Dicho todo esto, podemos estar en desacuerdo sobre si un artículo en particular debería o no haber sido redactado. Usted dice que la evidencia presentada muestra que no estaba justificado que esos artículos fueran enviados a redacción. Sin embargo, al revisar las fuentes, parece que la redacción estaba justificada. Esa es una diferencia de opinión. Onel 5969 TT me 14:20, 30 de septiembre de 2024 (UTC) [ responder ]
En su opinión, mover un artículo al espacio Borrador es simplemente una medida de control de calidad .
En mi opinión, mover un artículo al espacio Borrador: es también simplemente una medida de control de calidad que, comparada con las alternativas disponibles de dejarlo en el espacio principal, enviarlo a AFD o moverlo al espacio Usuario:, disminuye sustancialmente la probabilidad de que se mejore la calidad y aumenta sustancialmente la probabilidad de que el artículo sea eliminado.
Ah, cierto: esos dos últimos puntos ( «disminuye sustancialmente la probabilidad de que se mejore la calidad» y «aumenta sustancialmente la probabilidad de que se elimine el artículo» ) no son «opiniones». Son hechos objetivos. WhatamIdoing ( discusión ) 22:17 30 sep 2024 (UTC) [ responder ]
La clase 19 de Rhodesia Railways no es una lista; es un tren que estuvo en funcionamiento durante varios períodos de tiempo. Incluso si fuera una lista, los encabezados vacíos y el hecho de que solo haya una tabla de contenido no se acercan en nada a la clase inicial, tal vez ni siquiera a un substub. Aaron Liu ( discusión ) 20:47 29 sep 2024 (UTC) [ responder ]
El contenido existente en el artículo es un cuadro de información y una tabla. Las tablas son el formato preferido por Wikipedia:Listas destacadas . Las secciones vacías no están prohibidas y las calificaciones se basan en lo que ya está allí. Lo calificaría como |class=Listhoy. WhatamIdoing ( discusión ) 20:53 29 sep 2024 (UTC) [ responder ]
El único contenido es una tabla . ¿Has leído la página? Ese cuadro de información está lleno de contenido, hay dos fuentes aparentemente confiables y la tabla en sí tiene alrededor de 20 filas de contenido. Thryduulf ( discusión ) 21:33 29 sep 2024 (UTC) [ responder ]
Lo siento, sí, también el cuadro de información. De todas formas, no lo consideraría un comienzo. Aaron Liu ( discusión ) 22:03 29 sep 2024 (UTC) [ responder ]

¿Podemos considerar cambios pendientes a nivel CE?

Esta es solo una idea y quiero trabajarla un poco más, pero creo que sería útil tener cambios pendientes en el nivel de confirmación extendida. Esto podría llamarse "PC2" nuevamente (no confundirse con el PC2 original) o "PCECP". La idea sería ayudar a hacer cumplir WP:ARBECR y restricciones similares donde los usuarios no confirmados por la extensión tienen prohibido el acceso a ciertas áreas temáticas. En este nivel, las ediciones de editores no confirmados por la extensión se retendrían para su revisión, mientras que los usuarios confirmados por la extensión pueden aprobar estas ediciones y, por lo tanto, asumir la responsabilidad en virtud de WP:PROXYING .

Creo que sería útil para páginas en las que (1) partes del artículo se cruzan con un tema polémico, o (2) el artículo en su totalidad se cruza con un tema polémico, pero no se edita con frecuencia. Awesome Aasim 16:54, 27 de septiembre de 2024 (UTC) [ responder ]

Parece que esto podría ser útil. Debería restringirse a páginas que se editan con poca frecuencia (probablemente excluyendo todos los artículos de eventos actuales) para no sobrecargar Cambios pendientes cada vez que Reuters publica una nueva historia o estalla una guerra de ediciones. La gran pregunta es: ¿qué problema estás tratando de resolver? Toadspike [Discusión] 20:39, 27 de septiembre de 2024 (UTC) [ responder ]
Existen algunos temas polémicos designados por ArbCom o la comunidad en los que solo los usuarios confirmados pueden participar. Sin embargo, los administradores se niegan a proteger páginas en las que no hay suficientes interrupciones como para justificar la protección. Sin embargo, se debe tener en cuenta que la restricción XCON se aplica independientemente de si una página está protegida o no.
Lo que haría PCECP es básicamente eliminar los temores de que "no haya suficiente interrupción para justificar la protección" mientras se almacenan en búfer todas las contribuciones no confirmadas por extensión para que tengan que ser aprobadas, de acuerdo con "las no confirmadas por extensión solo pueden realizar solicitudes de edición". Las plantillas que son específicamente para este caso, como {{ edit protected }}, se rompen cuando la página no está protegida. Awesome Aasim 22:00, 27 de septiembre de 2024 (UTC) [ responder ]
El problema es que la regla 500/30 está diseñada específicamente para mantener a los editores más nuevos fuera debido a las cantidades extremas de interrupciones como regla. Hay una buena razón por la que las dos principales guerras candentes del mundo ( el conflicto árabe-israelí y la guerra ruso-ucraniana ) están bajo la regla 500/30. Y, como se ha mencionado repetidamente y vale la pena repetirlo nuevamente, los altos volúmenes de ediciones en un artículo determinado contraindican el bloqueo CRASH.
Pero el mayor obstáculo aquí es que todavía no existe un consenso para un CRASHlock confirmado de forma extendida. La última discusión sobre la expansión de CRASHlock a niveles de protección más altos es anterior a XCP por completo. Tendría que haber una RfC formal para esto, no una mera especulación del vicepresidente. — Jéské Couriano v^_^v hilos críticas 15:37, 28 de septiembre de 2024 (UTC) [ responder ]
La protección XCON tiene sentido para artículos con mucho tráfico, pero ¿para artículos con poco tráfico? Si la edición es menor, como corregir errores ortográficos o gramaticales, no debería haber ningún problema. De todos modos, corregir la ortografía y la gramática generalmente no es una área de discusión polémica. De WP:ARBECR : En cualquier página donde la restricción no se aplique a través de la protección confirmada extendida, esta restricción puede aplicarse mediante otros métodos, incluido... el uso de cambios pendientes.
Probablemente también establecería filtros de abuso para ver si una página está en una categoría que trata principalmente sobre un tema polémico y luego advertir y etiquetar la edición en cuestión. Awesome Aasim 16:22, 28 de septiembre de 2024 (UTC) [ responder ]
La mayoría de los artículos de CT con poco tráfico no tienen ninguna protección, ya que nunca han sufrido cantidades de vandalismo que la requieran. Las solicitudes de protección que dependen únicamente de la aplicación de arbitraje y de poca o ninguna evidencia de vandalismo son rechazadas. Aaron Liu ( discusión ) 23:26 28 sep 2024 (UTC) [ responder ]
Sí, lo veo, pero el problema es que una edición que no sea de XCON se aprobará en páginas que no estén viendo muchas personas. Los cambios pendientes aún permiten que los usuarios que no sean de XCON realicen estas ediciones, pero sus ediciones deberán ser aprobadas y se pueden revertir si infringen WP:ARBECR . Esto también está en línea con la forma en que se utilizan los cambios pendientes en artículos de poco tráfico para monitorear (no prevenir) las interrupciones. Awesome Aasim 18:26, 29 de septiembre de 2024 (UTC) [ responder ]
@ Aaron Liu La mayoría de los artículos de CT con poco tráfico no tienen ninguna protección, ya que nunca vieron cantidades de vandalismo que requirieran protección. Las solicitudes de protección que dependen únicamente de la aplicación de arbitraje y poca o ninguna evidencia de vandalismo son rechazadas. No es cierto, los artículos en temas de ECR pueden y son bloqueados de manera preventiva. Lo que realmente sucede es que los artículos con una interrupción mínima generalmente no se llevan a WP:RFPP ni son detectados por un administrador desobediente. Mach61 19:53, 29 de septiembre de 2024 (UTC) [ responder ]

No es cierto. Los artículos en los temas de ECR pueden bloquearse preventivamente.

¿Podrías añadir un ejemplo? Hay una larga lista de solicitudes de RFPP rechazadas para la ejecución del arbitraje. Aaron Liu ( discusión ) 20:42 29 sep 2024 (UTC) [ responder ]
Vea este intercambio entre un administrador que se negó a brindar protección en base a ECR debido a la falta de interrupciones y un (ex) administrador que les explicó lo contrario. Mach61 19:46, 1 de octubre de 2024 (UTC) [ responder ]
Gracias, ahora entiendo el "puedo". Aaron Liu ( discusión ) 20:59 1 oct 2024 (UTC) [ responder ]
Parece razonable. Siempre me he preguntado por qué los cambios pendientes no se implementan con más frecuencia. Parece una herramienta útil y hay muchos revisores de cambios pendientes, por lo que hay muy poca acumulación de trabajo. Cremastra ( discusión ) 14:18, 28 de septiembre de 2024 (UTC) [ responder ]
Porque hay suficientes personas a las que les desagradan o desconfían de los cambios pendientes, por lo que es difícil llegar a un consenso para utilizarlos. Véase, por ejemplo, Wikipedia:Village pump (propuestas)/Archivo 183#RFC: Pending-changes protection of Today's featured article . Anomie ⚔ 14:41, 28 de septiembre de 2024 (UTC) [ responder ]
Bueno, caray, me pregunto por qué, carajo. — Jéské Couriano v^_^v hilos críticas 15:39, 28 de septiembre de 2024 (UTC) [ responder ]
¿Te importaría explicarme más sobre tu punto? No lo veo. Anomie ⚔ 17:04, 28 de septiembre de 2024 (UTC)[ responder ]

Quizás lo que se necesita es esto...

Una RfC de varias partes que pregunta cómo se debe aplicar el ECR para las páginas existentes, incluso en función de la actividad. Las páginas con mucho tráfico necesitarán protección extendida de forma retroactiva, ya que tienden a sufrir la mayor cantidad de interrupciones debido a las violaciones del ECR. Las páginas con poco tráfico, no tanto, pero podemos usar filtros de abuso y cambios pendientes del ECP del taller para esto. Las correcciones de ortografía y gramática, hasta donde yo sé, están excluidas de WP:ARBECR . Awesome Aasim 19:52, 1 de octubre de 2024 (UTC) [ responder ]

#### en [tema]

¿Deberían incluirse enlaces en los artículos sobre años en temas? Por ejemplo, el primer enlace de The Little Girl Lost es a 1794 en poesía . El enlace parece una violación de Wikipedia:OLINK , pero no se indica específicamente. Los enlaces a solo años ya desaparecieron, pero ¿por qué no se eliminan activamente los que tratan sobre temas? Roasted ( discusión ) 22:56, 28 de septiembre de 2024 (UTC) [ responder ]

Todo empezó en un año, y vincular ese año a un artículo sobre un montón de información irrelevante no es de ayuda. Pero en un artículo sobre un poema escrito en 1794, es bastante razonable vincular a un artículo sobre otras cosas muy relacionadas de ese año. Esa no es una regla, pero es una visión defendible, particularmente para poemas de hace 230 años, donde es un milagro que tengamos algún registro del poema. Johnuniq ( discusión ) 01:04 29 sep 2024 (UTC) [ responder ]
Creo que es una visión defendible, en especial para los temas que se analizan o enlazan en el artículo. Es similar a nuestro principio WP:BIDIRECTIONAL para los cuadros de navegación: si puedes llegar desde 1794 en poesía hasta La niña perdida , entonces sería ideal que pudieras regresar.
Creo que es más defendible para temas más breves y específicos que para páginas extensas. 1794 en poesía está bien. 2023 en cine tal vez no. WhatamIdoing ( discusión ) 01:23 29 sep 2024 (UTC) [ responder ]
La lista de películas alemanas de 2023 , de las que se puede llegar con derecho a 2023 en el cine , podría ser una historia diferente. Thryduulf ( discusión ) 10:19 29 septiembre 2024 (UTC) [ responder ]
Dejaría eso al criterio de los editores y no me opondría a nada de lo que decidieran.
Otra cosa a tener en cuenta es el formato. Compara estas oraciones:
Para el primero, la etiqueta del enlace es "poema de 1794", y si te sorprende que al hacer clic en "poema de 1794" te lleve a 1794 en poesía , entonces quizás no estabas prestando atención a lo que estabas haciendo clic.
En el segundo, la etiqueta del enlace es "2023", y se podría esperar que aparezca 2023 en lugar de películas de 2023. Sugeriría cambiar ese enlace para que incluya las palabras "en 2023" en lugar del año solamente. WhatamIdoing ( discusión ) 19:37 29 sep 2024 (UTC) [ responder ]
Mis 2¢: eliminen los enlaces directos, pero coloquen los artículos "AÑO en TEMA" en la sección "ver también". Esto elimina cualquier problema con MOS:EGG y, en todo caso, es más coherente con una analogía con los cuadros de navegación bidireccionales. Mach61 03:35, 30 de septiembre de 2024 (UTC) [ responder ]
Me gusta esto.
(Hombre, ojalá los cuadros de navegación estuvieran en esa sección. Aaron Liu ( discusión ) 11:43 30 sep 2024 (UTC) [ responder ]

Bots de expansión de URL

Estoy de acuerdo en que las URL cortas no son deseables. Sin embargo, ¿no sería mejor si un bot expandiera automáticamente esas URL en lugar de incluirlas en la lista negra? Por ejemplo, youtu.be en youtube.com/watch?v= , tinyurl.com/example en example.com (ese es su objetivo real). Elominius ( criticar | contribuciones ) 09:19, 30 de septiembre de 2024 (UTC) [ responder ]

El motivo por el que están en la lista negra no es porque sean "indeseables", sino porque pueden usarse (y se han usado) para eludir la lista negra de spam y otras medidas antispam. Si el enlace es legítimo, no hay motivo por el que el usuario que intenta agregarlo no pueda expandirlo. Anomie ⚔ 11:25, 30 de septiembre de 2024 (UTC) [ responder ]

Creación de plantilla: cuadro de información de Wikidata

Hola, propongo crear una plantilla llamada Template:Wikidata Infobox que crea un cuadro de información a partir de la información que existe en Wikidata. La misma idea se implementa en WikiCommons. Véase https://commons.wikimedia.org/wiki/Wikipedia:Village_pump_(idea_lab)/Category:Quantum_computing y la sección infobox que utiliza {{Wikidata Infobox}}. Saludos. Hooman Mallahzadeh ( discusión ) 13:33 1 oct 2024 (UTC) [ responder ]

El uso de Wikidata para los infoboxes se ha discutido muchas veces aquí y es sorprendentemente (para mí) controvertido. Algunos infoboxes específicos incorporan información de Wikidata (si no recuerdo mal, Mike Peel ha trabajado un poco en esto), pero no creo que un único infobox genérico, ya sea que extraiga información de Wikidata o de otra manera, logre un consenso. Dejaré una nota sobre esta discusión en Wikipedia talk:WikiProject Infoboxes y Wikipedia talk:WikiProject Wikidata . Thryduulf ( discusión ) 13:42 1 oct 2024 (UTC) [ responder ]
Sí... hay MUCHA resistencia a la hora de importar datos de Wikidata a nuestras cajas de información. Las dos principales preocupaciones son la verificabilidad/fiabilidad (aunque WD ha mejorado en este aspecto, todavía no se ajusta a nuestras políticas) y la facilidad de edición (tener que ir a WD para editar la información que aparece en WP puede resultar confuso).
Compartiré una experiencia personal de confusión... la estructura centrada en los datos de WD a menudo me resulta incomprensible como editor centrado en texto aquí en WP. Cuando intento corregir errores en WD, tengo una dificultad extrema para hacerlo. Simplemente localizar la información que necesito editar es difícil. La forma en que se organizan y estructuran las páginas de WD es un galimatías extraño para mí. Blueboar ( discusión ) 14:18, 1 de octubre de 2024 (UTC) [ responder ]
Wikidata es una buena idea a falta de una interfaz utilizable. Su uso se vería enormemente facilitado si se pudieran editar los datos aquí y se volcaran a Wikidata. -- LCU A ctivamente desinteresada « @ » ° ∆t ° 14:39, 2 de octubre de 2024 (UTC) [ responder ]
Así es como se configuran la mayoría de los Wikivoyages. No es automático (excepto posiblemente en alemán), por lo que tienes control total sobre qué partes importas localmente y qué partes de tu contenido envías de vuelta a Wikidata. El control es importante porque algunos contenidos son diferentes. Por ejemplo, Wikivoyage normalmente quiere poner la ubicación de latitud y longitud en la entrada de una ubicación, y Wikidata normalmente quiere el centro. No hay necesidad de anular las ubicaciones de cada uno si resultan ser significativamente diferentes (por ejemplo, entrada a Disney World vs. centro de Disney World). Cuando son las mismas, entonces puedes compartirlas de ida y vuelta. WhatamIdoing ( discusión ) 04:23, 3 de octubre de 2024 (UTC) [ responder ]
Commons solo tiene un tipo de cuadro de información. Tenemos muchos de ellos que muestran datos muy diferentes. Personalmente, me encantaría incorporar Wikidata en casi todos los cuadros de información, pero es imposible que un cuadro de información genérico se adapte a nuestras necesidades. Aaron Liu ( discusión ) 14:14 1 oct 2024 (UTC) [ responder ]
Realmente creo que este tipo de infobox (quizás en forma de colapso) es el mejor reemplazo para el infobox de artículos para los que no podemos crear ningún infobox como Computación cuántica . Estos datos incluyen enlaces a WikiQuote y su id de biblioteca, etc., lo que los hace accesibles y a mano. Propongo usar este tipo de infobox en otras secciones como la sección "Ver también", en lugar de la parte superior, reemplazando muchas plantillas existentes como {{Categoría Commons}}. Hooman Mallahzadeh ( discusión ) 14:32 1 oct 2024 (UTC) [ responder ]
Um, ¿qué valor se podría derivar del uso de d:Q17995793 para completar un cuadro de información para el artículo Computación cuántica ? ¿Realmente necesitamos un cuadro de información para ese artículo para aclarar que el tema es una instancia de "disciplina académica", subclase de "computación", y es el estudio de la "computadora cuántica" y/o la "supremacía cuántica"? Este es un excelente ejemplo de un artículo que no necesita un cuadro de información. Folly Mox ( discusión ) 02:31 2 oct 2024 (UTC) [ responder ]
Ah, veo que quieres usar el cuadro de información que se encuentra al final de un artículo como un cuadro de navegación. Eso es menos objetable y también es un tipo diferente de cuadro en nuestra jerga. Folly Mox ( discusión ) 02:44 2 oct 2024 (UTC) [ responder ]
@ Hooman Mallahzadeh , no todos los artículos se benefician de un cuadro de información. En mi opinión, la computación cuántica es uno de ellos. Remsense  ‥ 论06:14, 2 de octubre de 2024 (UTC) [ responder ]
@ Remsense Hay buenos enlaces a WikiQuote, Wikiversity, Wikidata, WikiCommons, Library of Congress Authority ID, que se adjuntan al artículo principal simplemente transcluyendo esta plantilla. Esto es un gran beneficio para Wikidata-Infobox de la computación cuántica . Pero colapsar este Wikidata Infobox por defecto parece razonable. Hooman Mallahzadeh ( discusión ) 06:26 2 oct 2024 (UTC) [ responder ]
Ya podemos hacerlo enlazando a los que son importantes en la parte inferior. ¡Esto es extremadamente común y ya se hace en ese artículo! Sin embargo, eso plantea un punto clave de resistencia a esto. No queremos subcontratar mucho a Wikidata porque no podemos decidir tan fácilmente qué no mostrar, para no contaminar los artículos con metadatos que pueden ser útiles en una base de datos pero que son basura funcionalmente inútil en un artículo de enciclopedia. Fundamentalmente, nunca deberíamos esperar que los editores tengan que usar también Wikidata. Remsense  ‥ 论06:28, 2 de octubre de 2024 (UTC) [ responder ]
Este método es un poco complicado, pero me parece más razonable insertar enlaces acumulativos «por plantilla». Hooman Mallahzadeh ( discusión ) 06:31 2 oct 2024 (UTC) [ responder ]
No, porque la decisión de si vale la pena vincular a Wikiquote en un artículo determinado debería corresponder a los editores de ese artículo. Remsense  ‥ 论06:32, 2 de octubre de 2024 (UTC) [ responder ]
No estoy de acuerdo. Según el efecto Zeigarnik , colocar un enlace de Wikiquote que está vacío en este momento motiva a los usuarios a completar esa página y poner alguna cita sobre ese concepto. Hooman Mallahzadeh ( discusión ) 06:38 2 oct 2024 (UTC) [ responder ]
No es nuestro trabajo construir Wikiquote, pero sí es nuestro trabajo no atiborrar indiscriminadamente los artículos de nuestra enciclopedia con basura inútil. Tu postura sería molestada por casi cualquier editor al que le importe el aspecto de los artículos que escribe y qué es exactamente lo que presenta a los lectores. Remsense  ‥ 论06:59, 2 de octubre de 2024 (UTC) [ responder ]
A la mayoría de los lectores no les importan esas cosas. Los pocos a los que les importa se conforman con que estén en la parte inferior. Aaron Liu ( discusión ) 11:34 2 oct 2024 (UTC) [ responder ]
Hooman Mallahzadeh , tu idea de una única plantilla de uso general para crear enlaces de proyectos hermanos a partir del elemento Wikidata asociado para su uso en la ==External links==sección suena como una buena idea, pero la gente de este subproceso se ha sentido confundida por tu uso del término infobox (que se encuentra en la parte superior del artículo). Sin embargo, esto suena idéntico a la plantilla existente {{ Sister project auto }} . ¿En qué se diferencia tu idea? Folly Mox ( discusión ) 12:35 2 oct 2024 (UTC) [ responder ]
Si la idea es mostrar alguna información de origen, también puede ser similar en concepto a la plantilla más utilizada {{ Control de autoridad }} . SamuelRiv ( discusión ) 15:07 2 oct 2024 (UTC) [ responder ]
Correcto, {{ authority control }} ya es omnipresente (~2.131.000 inclusiones de 6.890.950 artículos, incluidas las redirecciones), incluso está incluido en la salida predeterminada de Wikipedia:ArticleWizard y {{ authority control }} ya extrae de Wikidata. Folly Mox ( discusión ) 17:54, 2 octubre 2024 (UTC) [ responder ]
Teniendo en cuenta todo esto, @Hooman Mallahzadeh , te sugiero que simplemente hagas/bifurques una plantilla en esa línea (o que edites la plantilla existente en su entorno de pruebas), ya que este concepto básico no generaría controversia. El resto de la discusión aquí es un desorden hipotético hasta que la gente vea exactamente lo que tienes en mente, que puede ser radicalmente diferente de lo que ya se usa en estas plantillas anteriores. SamuelRiv ( discusión ) 18:41, 2 de octubre de 2024 (UTC) [ responder ]
Algo como Categoría:Tierra muestra lo difícil que es obtener un cuadro de información automático y bueno, y no un montón de entradas extrañas. "Instancia de: "planeta interior del Sistema Solar (Marte, Venus)" ¿Y Mercurio? Si por alguna razón enumeras los demás aquí, enumeralos todos... "Nombrado por: *suelo (Tierra) *tierra (1, 地, 地球) *esfera (2, 球, 地球)" Er, ¿qué? No tengo idea de por qué se muestra el japonés aquí. "Origen: 4.541.º milenio a. C. (datación de plomo-plomo, edad de la Tierra, creacionismo de la Tierra joven)" Sí, seguro que queremos un enlace al creacionismo de la Tierra joven aquí... "Fecha de disolución, abolición o demolición: valor desconocido (futuro de la Tierra)" Ni siquiera un enlace, solo el texto, como si esto fuera de alguna manera útil. Y esto no es un ejemplo oscuro. Fram ( discusión ) 14:30 1 oct 2024 (UTC) [ responder ]
{{ Persona del cuadro de información/Wikidata }} , ¿alguien? -  Charla Qwerfjkl 18:42, 1 de octubre de 2024 (UTC)[ responder ]
Qué gran manera de introducir información no verificada (errores) y tonterías en los artículos de Wikipedia. -- Ssilvers ( discusión ) 20:46 1 oct 2024 (UTC) [ responder ]
La información no verificada y la información incorrecta (lo que supongo que quieres decir con "errores") no son sinónimos. No todo en WikiData es información no verificada, incorrecta o sin sentido. Thryduulf ( discusión ) 20:51 1 oct 2024 (UTC) [ responder ]
@ Ssilvers Hay un parámetro fácil para incluir solo información con referencias. Existen referencias incorrectas y se pueden corregir fácilmente utilizando los mismos métodos en ambos sitios. Aaron Liu ( discusión ) 21:01, 1 de octubre de 2024 (UTC) [ responder ]
Wikidata tiene diferentes estándares de fuentes que enwiki: los sitios que se consideran poco fiables según el consenso de enwiki se consideran bastante buenos en Wikidata. Las entradas de Wikidata también se excluyen de los mecanismos de limpieza existentes enwiki. Por lo tanto, no es tan sencillo como sugieres aplicar los mismos métodos a ambos sitios: los dos sitios no tienen ni los mismos métodos ni una comprensión compartida de lo que es una "mala referencia". Nikkimaria ( discusión ) 00:22 2 oct 2024 (UTC) [ responder ]
¿ Alguien está intentando desarrollar un entendimiento compartido, o todo el mundo piensa que está bien que el sitio esté desconectado de esa manera, aunque podrían ayudarse mucho más entre sí? Si tienes enlaces a discusiones, me encantaría leerlas. Amir E. Aharoni ( discusión ) 00:46 2 oct 2024 (UTC) [ responder ]
Mi percepción es que hay una apatía mutua en ambas bases de usuarios: la gente que escribe una enciclopedia no es coherente con la gente que quiere construir una base de datos universal. Si bien los resultados son desafortunados, realmente sería poco razonable esperar que un grupo de voluntarios opere de acuerdo con los estándares del otro. Remsense  ‥ 论06:07, 2 de octubre de 2024 (UTC) [ responder ]
Entonces deberíamos informar a Wikidata por qué y cuáles fuentes son malas y a menudo falsas. No veo ninguna fuente que se considere muy válida en Wikidata y que se elimine sin previo aviso en Wikipedia. Aaron Liu ( discusión ) 01:10 2 oct 2024 (UTC) [ responder ]
[1]. Nikkimaria ( discusión ) 01:25 2 oct 2024 (UTC) [ responder ]
@ Nikkimaria , ¿fue esto una respuesta para mí? ¿Solo un comentario de una persona? Amir E. Aharoni ( discusión ) 02:15 2 oct 2024 (UTC) [ responder ]
No era una respuesta para ti. Este sería un mejor lugar para comenzar con tu pregunta, aunque esa perspectiva también es relevante. Nikkimaria ( discusión ) 02:32 2 oct 2024 (UTC) [ responder ]
Gracias, punto tomado. En ese caso, necesitamos tener al menos anulaciones específicas de parámetros. Aaron Liu ( discusión ) 02:43, 2 octubre 2024 (UTC) [ responder ]
Curiosamente, uno de los argumentos de esa RfC es "Find a Grave se obtiene de las lápidas". ¿No sería mejor citar la lápida en ese caso? Sin embargo, me estoy desviando del tema. Aaron Liu ( discusión ) 02:46 2 oct 2024 (UTC) [ responder ]
La afirmación de que Wikidata está equivocada es sólo una afirmación. Es una wiki, está estrechamente integrada con Wikipedia y puede ser tan correcta o tan incorrecta como la propia Wikipedia. Amir E. Aharoni ( discusión ) 21:06 1 oct 2024 (UTC) [ responder ]
Sí, sabemos que Wikipedia tiene fallas… Por eso NO consideramos que Wikipedia sea una fuente confiable y NO usamos una parte de Wikipedia para verificar otras partes de Wikipedia. Blueboar ( discusión ) 21:18 1 oct 2024 (UTC) [ responder ]
Pero, ¿qué hay de malo en eso si podemos verificar por máquina que la parte reutilizada tiene una fuente? No se trata de buscar fuentes en Wikidata, se trata de reutilizar contenido fuente de Wikidata, por todas las razones por las que {{ extracto }} es bueno. Aaron Liu ( discusión ) 21:20 1 oct 2024 (UTC) [ responder ]
¿Alguien está sugiriendo que se use Wikidata para verificar cosas en Wikipedia? No lo creo. Desde luego que no.
En algunos casos, la gente sugiere insertar cosas escritas en Wikidata en la Wikipedia en inglés cuando es más eficiente hacerlo. Se pueden verificar como la propia Wikipedia. Amir E. Aharoni ( discusión ) 21:32 1 oct 2024 (UTC) [ responder ]
No creo que Wikipedia deba priorizar la eficiencia. Deberíamos priorizar el cuidado. Si la gente quiere reutilizar contenido de Wikidata, puede añadir el contenido y la fuente. No deberíamos simplemente invitarlo a que entre sin editar. Folly Mox ( discusión ) 02:41 2 oct 2024 (UTC) [ responder ]
Parafraseando a Shrek: Pero está curado . ¿Cuál es la diferencia si está curado por un editor de Wikipedia o por un editor de Wikidata? Wikidata no es un sitio completamente separado. Los dos sitios siempre han estado estrechamente relacionados en términos de comunidad y tecnología, y con el mismo objetivo final de conocimiento libre editado como una wiki. Si hay diferencias entre ellos en la política de verificabilidad, pensaría en tratar de salvarlas en lugar de descartar la idea de la colaboración por completo. Amir E. Aharoni ( discusión ) 13:43, 2 de octubre de 2024 (UTC) [ responder ]
No deberíamos dejar la curaduría del contenido incluido en los artículos en manos de personas que, por lo general, no consultan ni editan directamente dichos artículos. Esto me parece muy obvio. Remsense  ‥ 论13:51, 2 de octubre de 2024 (UTC) [ responder ]
Pero ¿por qué crees que no miran los artículos? Muy a menudo edito cosas en Wikidata porque noto que aparecieron incorrectamente en Wikipedia, y luego compruebo que la información se actualizó correctamente tanto en Wikidata como en Wikipedia. (Esto sucede más en otros idiomas, como hebreo, español o ruso, porque la Wikipedia en inglés usa Wikidata menos).
¿Y cuál es la diferencia entre cambiar algo en Wikidata que se incluirá en un artículo de Wikipedia y cambiar una plantilla dentro de Wikipedia que se incluirá en otras páginas? (Aparte de la URL diferente). O cambiar una imagen en Commons y Amir E. Aharoni ( discusión ) 14:00, 2 octubre 2024 (UTC) [ responder ]
Los procesos de curación entre los dos sitios son completamente diferentes. en.wiki se cura principalmente a nivel de página individual, mientras que wikidata parece curarse principalmente en secciones transversales donde se cruzan muchas páginas. (También vale la pena considerar cuánto de Wikidata es creado por bots que extraen de otras wikis). CMD ( discusión ) 14:03, 2 de octubre de 2024 (UTC) [ responder ]
¡Porque están editando una base de datos! Puede que ni siquiera hablen inglés, y mucho menos tengan en cuenta los matices de cómo la Wikipedia en inglés (o cualquier otro proyecto, para ser claros) puede verse afectada por lo que están haciendo directamente. Aunque pienses que no son sitios web totalmente diferentes, son sitios web diferentes. Realmente no creo que tenga que ponerme sociológico para discutir aquí un conjunto de hechos sociales que son bastante obvios para todos los que contribuyen a un proyecto de Wikimedia. "Wikipedia es un sitio, Wikidata es otro" también debería responder a tu segunda pregunta: si alguien rompe una plantilla, no es un cambio de paradigma que yo la arregle o le pida a alguien más que lo haga, porque eso ocurre en el mismo sitio web . Eres un espíritu libre y eso está bien; cualquier decisión de diseño que asuma esta calidad de los contribuyentes en general sería terrible. Remsense  ‥ 论14:11, 2 de octubre de 2024 (UTC) [ responder ]
Otra forma de pensarlo es que son el mismo sitio web con diferentes URL.
Y no estoy seguro de a qué te refieres con "calidad de los colaboradores" y "espíritu libre" hacia el final. En mi opinión, un espíritu libre en una enciclopedia libre es algo bueno, pero sospecho que te refieres a algo diferente. Amir E. Aharoni ( discusión ) 19:08 2 oct 2024 (UTC) [ responder ]
Wikidata es, sin duda, un sitio muy diferente, omnipresente en sus bajos estándares de inclusión. Aaron Liu ( discusión ) 19:29 2 oct 2024 (UTC) [ responder ]
Eso, en sí mismo, no es un problema. Puedes incluir algunas cosas de Wikipedia y excluir otras. Eso es más o menos lo que ocurre en la Wikipedia en inglés, pero ocurre más en otros idiomas y funciona bastante bien allí. No entiendo la resistencia que tienen algunos wikipedistas ingleses a incluir algo de Wikidata. Amir E. Aharoni ( discusión ) 16:14 3 oct 2024 (UTC) [ responder ]
Estoy de acuerdo en que no es un problema. No estoy de acuerdo con lo que dijiste sobre que son el mismo sitio y están estrechamente relacionados. Aaron Liu ( discusión ) 17:11 3 oct 2024 (UTC) [ responder ]
Ellos:
  • Son mantenidos por la misma organización.
  • Están construidos desde el principio para estar conectados, de manera similar a los Bienes Comunes.
  • Compartir cuentas de usuario.
  • Comparten una gran parte de la comunidad de edición. No tengo cifras precisas y, por supuesto, hay algunos editores de Wikipedia que no hacen nada en Wikidata y viceversa, pero hay mucha superposición.
¿Qué te hace pensar entonces que no están estrechamente relacionados? Amir E. Aharoni ( discusión ) 22:06 3 oct 2024 (UTC) [ responder ]
El hecho de que estén estrechamente relacionados en términos de infraestructura subyacente y objetivos superpuestos no equivale a que sean el mismo sitio web con diferentes URL. Por diseño, cada wiki de Wikimedia tiene su propia comunidad, con su propia cultura, que define sus propias pautas y procedimientos operativos. isaacl ( discusión ) 22:14 3 oct 2024 (UTC) [ responder ]
Lo único que intento decir es que no es muy diferente de Commons. Es independiente en algunos aspectos y es igual en otros. Algunos datos de Commons y Wikidata son útiles en la Wikipedia en inglés, otros no. Enfatizar solo las diferencias, como hacen algunos wikipedistas ingleses, no es correcto ni útil. Amir E. Aharoni ( discusión ) 22:22 3 oct 2024 (UTC) [ responder ]
En esencia, en.wiki solo toma de Commons las direcciones URL de los archivos. Es un lugar muy diferente a en.wiki y sus normas son muy diferentes. CMD ( discusión ) 23:24 3 oct 2024 (UTC) [ responder ]
Y, eh, los archivos, no sólo las URL, ¿verdad?
Independientemente de las normas internas que tenga Commons, la Wikipedia en inglés toma muchos archivos de ella. Y puede ocurrir lo mismo con Wikidata. La Wikipedia en inglés ya toma algunos datos de ella, y puede tomar más.
En realidad, no apoyo específicamente el uso del cuadro de información genérico de Wikidata en la Wikipedia en inglés. Solo intento comprender la resistencia que tienen algunos editores de la Wikipedia en inglés a incluir cualquier cosa de Wikidata. Amir E. Aharoni ( discusión ) 03:12 4 oct 2024 (UTC) [ responder ]
Los elementos clave de la resistencia se han explicado en otras partes de este hilo. Están relacionados con una menor calidad de las fuentes, una mayor vulnerabilidad al vandalismo y la dificultad para editar Wikidata. Los problemas de fuentes no se aplican a Commons, y las modificaciones de archivos allí están restringidas a aquellos con permisos avanzados. En.wiki no importa archivos de Commons, aunque sí aloja archivos por separado cuando no son elegibles para su inclusión en Commons. CMD ( discusión ) 04:17, 4 de octubre de 2024 (UTC) [ responder ]
Commons se beneficia de los requisitos compartidos establecidos por la Fundación Wikimedia sobre el uso de los medios, por lo que los archivos se pueden usar fácilmente en cualquier wiki de Wikimedia. (Por supuesto, los medios que incorporan información, como las estadísticas anuales, sufren problemas similares a los de Wikidata: su precisión depende de quién los cargue). Para aquellos preocupados por los estándares de verificación en Wikidata, desafortunadamente no tengo una buena sugerencia para crear mejores procesos para validar ediciones mientras se mantiene el enfoque de "cualquiera puede editar, todos verifican". Por su naturaleza, los datos son muy densos, por lo que creo que intentar verificar dos veces todas las ediciones entrantes es un trabajo más tedioso y oneroso del que se puede esperar que hagan los voluntarios. isaacl ( discusión ) 06:35, 4 de octubre de 2024 (UTC) [ responder ]
Sin embargo, los editores de Wikidata no seleccionan el contenido de los artículos: lo hacen los editores de las wikis que utilizan Wikidata. Wikidata es la información de origen y los editores deciden cuáles incluir. Por eso también creo que las plantillas deberían incluir modificaciones por parámetro antes de cambiar a Wikidata de forma predeterminada. Aaron Liu ( discusión ) 19:30, 2 de octubre de 2024 (UTC) [ responder ]
Hasta donde yo sé, las modificaciones por parámetro son lo que se hace en Wikipedia en todos los idiomas en los que las plantillas extraen información de Wikidata, y tiene todo el sentido. Si esta no es la situación en ningún lado, me sorprendería mucho. Amir E. Aharoni ( discusión ) 16:17 3 oct 2024 (UTC) [ responder ]
El Infobox de Wikidata en Commons surgió del trabajo inicial que estaba haciendo aquí en enwiki: es la misma base de código que {{ Infobox person/Wikidata }} y similares, pero evolucionó mucho más debido a una gran cantidad de aportes constructivos en Commons. Tiene dos vistas: una para las personas, otra para todo lo demás, y se ha demostrado que funciona muy bien en general, y es mucho más escalable y fácil de mantener que miles de plantillas más especializadas. Técnicamente, los infoboxes de Wikidata son bastante maduros ahora, y se usan mucho similares a este en Wikipedias de diferentes idiomas. Wikidata también está bastante bien integrado en diferentes flujos de trabajo en Wikimedia en la actualidad (incluso aquí con las listas rojas de WiR ). La pregunta principal es social: si la comunidad enwp está interesada en buscar infoboxes de Wikidata y dedicar el tiempo y la energía para contribuir de manera constructiva a mejorar los datos y refinar la lógica de las plantillas, como lo han hecho la comunidad de Commons y otras comunidades de Wikipedia en otros idiomas. Gracias. Mike Peel ( discusión ) 21:00 1 oct 2024 (UTC) [ responder ]
Creo que, a estas alturas, todavía tenemos demasiado miedo a lo desconocido y el síndrome de "no inventado aquí" como para aceptar mucha ayuda de Wikidata. Otras wikis se beneficiarán (y lo hacen), pero tendremos que ir mordisqueando los bordes durante otra década.
Es posible que debamos explorar algo más cercano a la sincronización manual pero bidireccional que utilizan los Wikiviajes (por ejemplo, para los sitios web oficiales y la latitud/longitud de lugares notables). Si no lo has visto, entonces ve a tu destino de vacaciones favorito en voy: (por ejemplo, voy:en:Paris/7th_arrondissement#See) y desplázate hacia abajo hasta que encuentres una sección que tenga [add listing]junto a los botones de edición de sección habituales. Haz clic en él y aparecerá un gran cuadro de diálogo. A la derecha, busca el espacio en blanco para Wikidata y escribe un monumento famoso (por ejemplo, "Torre Eiffel"; no guardará la edición hasta que se lo indiques manualmente). Haz clic en "búsqueda rápida" para ver lo que ofrece Wikidata (y luego en "Cancelar" hasta el final, para no realizar ningún cambio en el artículo o en Wikidata). También hay un cuadro de diálogo que te permite elegir partes individuales (por ejemplo, quiero mi URL pero la latitud/longitud de Wikidata, o reemplazar de forma remota la información antigua en Wikidata con información más reciente). Se podría hacer algo así, e incluso se podría configurar para que se requieran las fuentes. Agregar fuentes a Wikidata suele ser bastante fácil, ya que solo hay que elegir el tipo (por ejemplo, ISBN, DOI, URL...) y agregar el número de identificación/URL sin procesar directamente. WhatamIdoing ( discusión ) 05:49 2 oct 2024 (UTC) [ responder ]
Aunque estoy de acuerdo con tu evaluación de los procesos de decisión de WP, y realmente creo que lo ideal sería que hiciéramos más con los datos estructurados de WD en este caso, WD no facilita nada (haciéndome eco de lo que dijo Blueboar anteriormente) y, francamente (según mis intentos de plantearles este problema), no parece tener ninguna preocupación con el concepto de UX en absoluto. La interfaz de Commons funciona bien, pero tan pronto como te migra para editar los campos de Wikidata directamente, te ves obligado a utilizar su interfaz desconcertante y confusa, donde algo que debería ser tan básico como la diferencia entre una "propiedad" y una "referencia" (y dónde agregar una cita, lo cual se recomienda, pero que no es una "referencia") está por debajo de varios minutos de documentación. (Lo más extraño de todo esto es que en el Discord de WD parece que la gente coloca mal o no agrega datos es su tarea de mantenimiento número uno).
El proyecto (en su estado actual) es utilizable si podemos limitar la interacción del usuario tanto como sea posible, pero ni siquiera Commons ha podido hacerlo por completo. (Nota: me siento libre de quejarme de algunas de las ediciones de WD aquí porque ya he planteado estos mismos problemas a los editores de WD directamente muchas veces, a menudo con respuestas deficientes). SamuelRiv ( discusión ) 15:03, 2 de octubre de 2024 (UTC) [ responder ]
Las principales cosas que me gustaría tener en su lugar antes de poder respaldar una integración más profunda de Wikidata en los artículos de Wikipedia son:
  1. un marcador obvio en el código wiki de dónde se extrae un parámetro de Wikidata (como o algo así), con la capacidad de sobrescribirlo localmente simplemente sobrescribiéndolo o borrándolo|parameter=:wd
  2. mensajes de error más claros que hagan evidente a las personas sin experiencia en Wikidata qué dato falta en la plantilla o no puede entenderlo, que enlace directamente a la propiedad en el elemento de Wikidata que está causando el problema o, si no está presente, un enlace a la descripción de la propiedad y un enlace al elemento de origen
Me he encontrado con algunos errores de plantilla que surgieron en Wikidata, y en ningún caso pude resolverlos por mí mismo. Si los editores que están a favor de la integración con Wikidata están dispuestos a trabajar para que sus plantillas sean compatibles con los editores de Wikipedia con aptitud técnica moderada o inferior, entonces podría considerar sumarme, pero en la actualidad actúan como cajas negras inescrutables, y su efecto en la práctica es quitarle poder a un gran subconjunto de editores en esta comunidad. Folly Mox ( discusión ) 12:47 2 oct 2024 (UTC) [ responder ]
Estoy de acuerdo con esto. Recuerdo los fiascos cuando {{ fecha de inicio y edad }} gritaba cuando los datos wiki incorrectos devolvían varias fechas para un solo selector. Debería haber una manera de que estas plantillas se equivoquen sin que el error se sobrescriba con plantillas externas. Aaron Liu ( discusión ) 13:05, 2 de octubre de 2024 (UTC) [ responder ]

"Agregar fuentes a Wikidata suele ser bastante fácil, ya que simplemente eliges el tipo (por ejemplo, ISBN, DOI, URL...) y agregas directamente el número de identificación/URL sin procesar".

Elemento aleatorio [2], primera entrada sin fuente: "taxón". "Añadir referencia" abre el campo "propiedad", que da un menú desplegable con 5 posibilidades. Quiero usar un libro, así que supongo que "enunciado en" sería la opción correcta. Se abre un nuevo menú desplegable, con infinitas opciones, empezando por "¿humano"???, "¿asentamiento humano"???, pintura, aldea, apellido... ¿De qué diablos se trata esto? ¿Quizás deba introducir "libro" y puedo continuar? Ah, no, se queda ahí. Wikidata es extremadamente poco intuitiva y aleatoria. Fram ( discusión ) 08:32 2 oct 2024 (UTC) [ responder ]

Quiero usar un libro, así que supongo que "establecido en" sería la elección correcta.

Sí, solo tienes que introducir el nombre del libro... Esperar que pueda adivinar qué libro quieres citar es bastante poco razonable.
También puedes elegir simplemente "ISBN-13" en lugar de "indicado en". Aaron Liu ( discusión ) 11:38 2 oct 2024 (UTC) [ responder ]
Al igual que la sintaxis "poco intuitiva y aleatoria" de MediaWiki para introducir una referencia, Wikidata también tiene páginas de ayuda como wikidata:Help:Sources que explican exactamente esto. Aaron Liu ( discusión ) 11:43 2 oct 2024 (UTC) [ responder ]
Aunque es posible aprender leyendo el manual (¡eso espero!), creo que su desafío a la caracterización de que es simplemente "fácil" fue bastante justo. Remsense  ‥ 论11:54, 2 de octubre de 2024 (UTC) [ responder ]
Añadir una referencia en Wikidata es al menos tan fácil como en Wikipedia. El hecho de que los métodos no sean los mismos no cambia esto. Thryduulf ( discusión ) 11:58 2 oct 2024 (UTC) [ responder ]
No lo discuto. Remsense  ‥ 论11:59, 2 de octubre de 2024 (UTC) [ responder ]
Lo hago. Fram ( discusión ) 12:21 2 oct 2024 (UTC) [ responder ]
Una diferencia que vale la pena señalar es que en en.wiki alguien puede buscar Ayuda:Cita y encontrar algo, mientras que en Wikidata la mayoría de las páginas Ayuda: son elementos de Wikidata. Hay una guía en Wikidata:Ayuda:Fuentes, pero solo guía hacia fuentes que son elementos de Wikidata o URL. CMD ( discusión ) 12:31 2 oct 2024 (UTC) [ responder ]
Buen punto sobre la búsqueda fallida, pero hay un botón de "Ayuda" en el menú principal.
Parece que te perdiste la sección "Diferentes tipos de fuentes". Aaron Liu ( discusión ) 12:44 2 oct 2024 (UTC) [ responder ]
No estoy seguro de cómo llegas a esa extraña conclusión. La sección de diferentes tipos de fuentes es una guía para crear elementos de Wikidata, no para obtener sus fuentes. CMD ( discusión ) 13:05 2 oct 2024 (UTC) [ responder ]
Te guía sobre cómo puedes citar una base de datos con un ID de elemento (la base de datos es, de hecho, un elemento de Wikidata, pero, por lo general, el elemento para la base de datos que utilizas ya ha sido creado), una lápida, Wikisource y registros de archivo. Aaron Liu ( discusión ) 13:11 2 oct 2024 (UTC) [ responder ]
Esta conversación en cadena trata sobre la afirmación de que añadir una referencia a Wikidata es "normalmente bastante fácil", en el contexto de comparaciones con en.wiki. Si dijera que es fácil hacer referencia a algo en en.wiki, solo hay que crear un nuevo artículo para ello, sospecho que la gente no lo consideraría un argumento convincente ni una contribución útil. CMD ( discusión ) 13:16 2 oct 2024 (UTC) [ responder ]
Los nuevos elementos de Wikidata no son artículos. Su dificultad dista mucho de la de los nuevos artículos. Dicho esto, los elementos de referencia generados automáticamente a partir de, por ejemplo, una URL serían de gran ayuda. Aaron Liu ( discusión ) 16:21 2 oct 2024 (UTC) [ responder ]
Creo que subestimas la dificultad que puede tener la gente para crear elementos de Wikidata. CMD ( discusión ) 03:02 3 oct 2024 (UTC) [ responder ]
Es realmente fácil. Si bien el botón "Crear un nuevo elemento" en el menú principal no es muy visible, los pasos a partir de ahí son casi tan fáciles como completar {{ cite book }} . Aaron Liu ( discusión ) 17:12 3 oct 2024 (UTC) [ responder ]
Una vez creados los elementos, no es tan fácil como el agradable creador de citas en.wiki, pero, aparte de eso, no veo qué valor tiene ignorar a las múltiples personas que han manifestado que les resulta difícil analizar Wikidata. CMD ( discusión ) 23:28 3 oct 2024 (UTC) [ responder ]
Se prevé que Wikidata genere automáticamente elementos de referencia a partir de URL y, dado que se utilizará Citoid para generarlos, serán tan erróneos y absurdos como lo son aquí. Folly Mox ( discusión ) 16:14 3 oct 2024 (UTC) [ responder ]
Y eso significaría que los datos wiki incluidos en Wikipedia tendrían el mismo nivel de calidad que la wiki. Aaron Liu ( discusión ) 17:13 3 oct 2024 (UTC) [ responder ]
Eso no tiene ninguna lógica. Wikidata con una referencia generada por la herramienta tendría referencias similares a las generadas por esa herramienta si los editores involucrados son los mismos, y si el escrutinio posterior es el mismo. Pero como Wikidata tiene, por ejemplo, bots pobres que crean artículos o agregan referencias problemáticas, y no tiene el mismo nivel de control del vandalismo que Wikipedia (aunque también en este caso se escapan demasiadas cosas), el resultado final es que la calidad de Wikidata está con demasiada frecuencia muy por debajo de la calidad de Wikipedia. Fram ( discusión ) 18:07 3 oct 2024 (UTC) [ responder ]
Los elementos incluidos en las wikis serán examinados al igual que la wiki principal, y no estoy seguro de a qué contribuciones problemáticas de bots te refieres. Aaron Liu ( discusión ) 20:12 3 oct 2024 (UTC) [ responder ]
Como ejemplo, CJMbot[3]. Las últimas ediciones incluyen la creación de un elemento sobre un autor muy desconocido del siglo XVII[4], y luego, una semana después, la adición de los mismos elementos y referencias a él. Luego aparece otro bot y elimina los elementos duplicados, pero agrega las referencias duplicadas a los elementos anteriores. Bien hecho... Me di cuenta de este bot porque en John Cage agregó una segunda fecha de nacimiento[5] con origen en el Museo Dhondt-Dhaenens. Completamente inverificable, el museo existe, pero ¿qué significa? ¿Alguna base de datos, un catálogo, información dentro del museo? El resultado es que, por ejemplo, el cuadro de información en Commons, desde hace casi dos años, muestra la fecha de nacimiento correcta y una incorrecta. Fram ( discusión ) 07:56, 4 de octubre de 2024 (UTC) [ responder ]
Parece que ese bot ha destrozado incontables elementos de Wikidata, muchos de ellos de forma sutil, algunos de forma extremadamente flagrante. Se plantearon algunas preocupaciones en su página de discusión, pero a pesar de las garantías de que el propietario del bot lo investigaría, aparentemente no se hizo nada y nadie se dio cuenta de la enorme cantidad de interrupciones. Lo que, una vez más, me demuestra que deberíamos usar Wikidata lo menos posible y no confiar en que sea lo suficientemente bueno como para agregar contenido a enwiki. Véase [6], un compuesto químico que, gracias a este bot, también es un humano con una fecha de nacimiento, etc. No es un caso aislado, véase [7][8][9][10]... Fram ( discusión ) 10:12, 4 de octubre de 2024 (UTC) [ responder ]
"Sí, solo tienes que introducir el nombre del libro": ¿dónde? ¿Después del cuadro "indicado en"? "Indicado en" viene con una explicación extensa, que incluso en mi pantalla panorámica termina con "en el que se hace una afirmación..." sin ninguna posibilidad de acceder al resto de ese texto. ¿Qué sentido tiene el menú desplegable después de elegir "indicado en" si ninguna de estas opciones tiene sentido aquí? Pero bueno, agrego el título de un libro después de "indicado en". Vaya, quiero incluir un libro que no tiene una entrada en Wikidata: imposible (¿o qué otra cosa significa el cuadro rojo rosado?). Ah, cierto, según tu página de ayuda, si quieres usar una referencia que no existe ya como elemento en Wikidata, primero tienes que crear un elemento para ella. ¡Tan fácil! Si realmente no tienes suerte, es una referencia con diferentes ediciones, y luego tienes que crear dos nuevos elementos de Wikidata antes de poder usarlo como fuente. ¿Quieres usar un artículo de periódico como referencia? Primero crea un elemento de Wikidata para el artículo de periódico. En Wikipedia, utilizo el menú desplegable para el tipo de referencia que quiero añadir (solo se muestran cosas que realmente puedo usar, no "humanas"), me muestra cuáles son los campos estándar y no necesito crear otras cosas solo para poder obtener algo. Intentar editar Wikidata es simplemente una fuente interminable de frustración que evito felizmente y no quiero infligir a los demás en absoluto. Aún así, es agradable ver cómo el número de ediciones humanas en Wikidata se infla constantemente de forma artificial, por ejemplo, afirmando que he realizado 951 ediciones en Wikidata en lugar de una docena o más. Bueno, he marcado como favoritos 5 fragmentos de vandalismo de Wikidata para ver qué tan rápido se revierten, ¿me ha divertido esa visita a Wikidata después de todo? Fram ( discusión ) 12:21, 2 de octubre de 2024 (UTC) [ responder ]

¿Dónde? ¿Después del recuadro "indicado en"?

Sí, hay una razón por la que el parámetro se llama "indicado en". Es más intuitivo que el ícono del libro en la barra de herramientas del editor de código fuente.

que incluso en mi pantalla panorámica termina con "en el que se hace una reclamación..." sin posibilidad de acceder al resto de ese texto

Se muestra completamente en mi resolución estándar de 1080p.

¿Qué sentido tiene el menú desplegable después de seleccionar "establecido en" si ninguna de estas opciones tiene sentido aquí?

Eso es igual que ocurre con el parámetro "enlace al autor", TemplateWizard (la forma visual de insertar plantillas) sugiere automáticamente todos los artículos que comiencen con lo que hayas escrito. Sin embargo, estoy de acuerdo en que, al igual que TemplateWizard, Wikidata no debería sugerir automáticamente cosas cuando no has escrito nada.

Primero tienes que crear un elemento para ello. ¡Así de fácil!

Es realmente fácil. Si bien el botón "Crear un nuevo elemento" en el menú principal no es muy visible, los pasos a partir de ahí son tan fáciles como completar {{ cite book }} .
Es un buen punto lo de tener que completarlo dos veces para el elemento de edición.

Me muestra cuáles son los campos estándar

Wikidata también lo hace. Cada clase de objetos (indicada por lo que escribas en "instancia de") tiene un conjunto recomendado de declaraciones que debes completar; estas se sugerirán automáticamente cuando hagas clic en el botón "agregar declaración". Aaron Liu ( discusión ) 12:58 2 oct 2024 (UTC) [ responder ]
Debes estar viendo una Wikidata (y Wikipedia) completamente diferente a la mía. Si el Editor Visual es tan malo como Wikidata, entonces esa es otra buena razón para no usarlo. No obtengo un ícono de "libro", obtengo un lindo menú desplegable de texto con "citar libro", "citar web", "citar noticias", etc. Campos estándar: dices "Wikidata también lo hace". No, no lo hace. Después de haber agregado un título de libro después de "se indica en", no sucede nada. No obtengo, por ejemplo, el parámetro de páginas, o "capítulo", ni nada. Solo tengo que saber cuáles son los esperados. Fram ( discusión ) 13:15, 2 de octubre de 2024 (UTC) [ responder ]
Si aprender a editar Wikipedia puede ser un poco complicado, aprender a usar Wikidata es como chocar contra una pared de ladrillos. Especialmente en dispositivos móviles, lo encuentro simplemente inutilizable. Sinceramente, creo que sería fácil de usar si tuvieras que escribir comandos SQL. Eso no es un ataque al concepto de Wikidata, sino más bien una crítica a su implementación. -- LCU A ctively D isinterested « @ » ° ∆t ° 14:49, 2 de octubre de 2024 (UTC) [ responder ]
Básicamente puedes SQL CMD ( discusión ) 14:57 2 oct 2024 (UTC)[ responder ]
Son puntos muy buenos. Aaron Liu ( discusión ) 16:22 2 oct 2024 (UTC) [ responder ]
Creo que el gadget Arrastrar y soltar está activado de forma predeterminada, y este video de 22 segundos de duración: https://www.youtube.com/watch?v=jP-qJIkjPf0 muestra que solo lleva un par de segundos importar una fuente directamente desde Wikipedia al campo de referencia en Wikidata.
Agregar manualmente una referencia como la que agregué aquí requiere muy pocos pasos:
  1. Haga clic en el botón "editar" de ese elemento (si aún no lo está editando).
  2. Haga clic en "+ agregar referencia".
  3. Seleccione un tipo de referencia de la lista desplegable. Esto puede requerir un poco de conocimiento previo (equivalente a saber cuál de las muchas plantillas de citas utilizar), pero generalmente sugiere algo sensato, como "URL de referencia".
  4. Pegue la URL (u otra información de referencia) en el cuadro.
  5. Haga clic en "publicar".
Estoy seguro de que todas las personas que participan en esta discusión son capaces de aprender a hacer esto, y estoy bastante seguro de que la mayoría de nosotros descubriría que solo lleva unos segundos después de haber aprendido los sencillos pasos del proceso. Esto requiere, como máximo, cuatro clics, pegar la fuente y, a veces, escribir el nombre de un tipo de referencia adecuado (si el tipo que desea no aparece ya en la lista).
El método de arrastrar y soltar no requiere tanto esfuerzo. Simplemente desplácese hasta la lista de Wikipedias al final del elemento Wikidata y haga clic en [ref] para el idioma del que desea copiar la referencia. Se abrirá una copia del artículo de Wikipedia. Busque la referencia que desea reutilizar y arrástrela. Copiar y pegar con la ayuda de un script no me parece una tarea difícil. WhatamIdoing ( discusión ) 04:18, 3 de octubre de 2024 (UTC) [ responder ]
Entonces, primero agrego la fuente a Wikipedia y luego la copio a Wikidata para poder, eh, usarla en Wikipedia. ¿Cómo hace esto la vida más fácil? El video usa el Jardín Botánico Mabery Gelvin [11] y agrega una segunda referencia al estado en el que se encuentra, Illinois. Entonces, si tuviéramos un cuadro de información generado a partir de Wikidata, habría mostrado que se encuentra en Illinois, tal como lo hace ahora. Aparte del hecho de que el estado ya no se menciona en Wikidata por alguna razón... Se agregó en 2016 (con una fecha de recuperación de 2012, no es bueno) y se eliminó hace más de un año. Menos mal que no dependemos de ese sitio. Teniendo en cuenta que ninguno de los 5 ejemplos de vandalismo que grabé ayer se han revertido, parece que las peleas por vandalismo en Wikidata siguen siendo problemáticas de todos modos. Fram ( discusión ) 07:38, 3 de octubre de 2024 (UTC) [ responder ]
La herramienta sirve para importar fácilmente citas existentes. Aún falta crear una herramienta que ayude a crear nuevas citas.
Además, el elemento de Wikidata se modificó para que se encuentre en el condado de Champaign, lo que parece correcto. Aaron Liu ( discusión ) 13:57 3 oct 2024 (UTC) [ responder ]
Como dijo Chipmunkdavis más abajo, la herramienta ni siquiera es visible para los simples mortales, ¿es un interruptor en las preferencias? Y no dije que el condado de Champaign sea incorrecto, sino que si el cuadro de información estuviera lleno de Wikidata, habría cambiado de "Illinois" (bueno, informativo para la mayoría de la gente, deseado) a "condado de Champaign" (no informativo para la mayoría de la gente, ciertamente sin "Illinois"). O, para ser aún más exactos, habría quitado "Illinois" del cuadro de información pero ni siquiera habría agregado "condado de Champaign" en su lugar, ya que en Wikidata, el condado de Champaign ni siquiera se menciona... EE. UU. tampoco se mostraría, ya que se "referencia" a enwiki. Las únicas referencias en el artículo son errores 404. No es un ejemplo que elegí deliberadamente, es uno dado por WhatamIdoing (aunque involuntariamente, supongo), pero es típico de Wikidata, incluso después de más de 10 años. Incluso cuando se consulta un artículo básico, como Illinois[12], no se encuentran fuentes fiables. Fram ( discusión ) 14:57 3 oct 2024 (UTC) [ responder ]
Sí, el gadget no está habilitado de manera predeterminada y debe activarse.
Nombrar ubicaciones como si estuvieran dentro de sus provincias es una convención de estilo independiente de los datos. Los cuadros de información podrían realizar fácilmente dos llamadas a Wikidata para obtener la ubicación. Aaron Liu ( discusión ) 15:29, 3 de octubre de 2024 (UTC) [ responder ]
No parece ser la opción predeterminada. Mi interfaz de Wikidata (incluida la de Mabery Gelvin Botanical Garden (Q5477670)) tiene los distintos enlaces wiki en la parte inferior de la página y sin los íconos [ref]. CMD ( discusión ) 09:30 3 oct 2024 (UTC) [ responder ]
Otra diferencia clave (en mi experiencia) entre WP y WD: en WP se reconoce que existe una curva de aprendizaje y barreras de entrada a la edición, y en prácticamente todas las conversaciones con VP se plantea la noción de cómo mitigar esto; en WD, las conversaciones que he tenido parecen indicar que los editores creen que es completamente intuitivo en su núcleo: o no creen que puedan hacerlo más fácil para los usuarios, o que las dificultades de los usuarios son su propia culpa (esta es solo la impresión que he tenido de las conversaciones; admito que soy muy directo a la hora de informar sobre los problemas de interfaz). Además, cuando se les preguntó, los editores de WD no parecían interesados ​​en realizar experimentos de interacción con el usuario o examinar los datos de UX existentes.
Nuevamente, esto no es para criticar a WD sin ningún motivo. Creo en el propósito principal del proyecto, pero en este punto siento que tengo que gritarle a cualquier dirección para que se despierten. SamuelRiv ( discusión ) 14:58 3 oct 2024 (UTC) [ responder ]
Este problema existe sin duda en Wikidata, pero también en Wikipedia. Amir E. Aharoni ( discusión ) 16:06 3 oct 2024 (UTC) [ responder ]

En cuanto al trabajo necesario para actualizar Wikidata: cuando hice un cambio por última vez, lo cual, admito, fue hace mucho tiempo, tuve que recorrer un largo camino creando elementos de Wikidata para cada valor de propiedad que añadí a la cita que no existía ya, lo que dio lugar a la creación en cascada de más elementos de Wikidata para los valores de propiedad de los elementos creados inicialmente, y así sucesivamente. Si este sigue siendo el caso, estaría mucho más inclinado a actualizar Wikidata si hubiera una herramienta que me ayudara a generar el árbol completo de elementos de Wikidata en cascada para que yo los aprobara para su envío. isaacl ( discusión ) 16:35 2 oct 2024 (UTC) [ responder ]

Continuación

Aunque la premisa inicial de este hilo es desafiante, creo que vale la pena reagruparse para deliberar específicamente sobre algunos otros conceptos y potencialidades con respecto a la integración de Wikidata que otros han planteado hasta ahora. En particular, creo que se acepta en general que una variedad de características son potencialmente viables siempre que sean transparentes de forma bidireccional, es decir, que los usuarios de Wikipedia no tengan que aprender a usar Wikidata o abandonar Wikipedia para obtener o actualizar información. Estamos bastante familiarizados con que esto es en parte la forma en que funcionan las descripciones breves, ¿no? Remsense  ‥ 论03:46, 3 de octubre de 2024 (UTC) [ responder ]

Creo que Wikidata extrae descripciones breves de en.wiki (¿y otros idiomas?) para su campo relevante solo cuando no existe una en Wikidata, y de manera similar, en.wiki solo muestra Wikidata si no hay una descripción breve de en.wiki (a menos que ya se haya deshabilitado). Wikidata también extrae coordenadas y otros elementos, pero no sé si gran parte de esto vuelve de forma bidireccional a en.wiki. CMD ( discusión ) 14:07 3 oct 2024 (UTC) [ responder ]
Puede encontrar más información sobre el uso de Wikidata en la Wikipedia en inglés en Wikipedia:Wikidata . Más de 100 Infoboxes utilizan Wikidata de alguna manera. Consulte Categoría:Plantillas de Infoboxes que utilizan Wikidata .
La otra dimensión que esta conversación deja de lado es que los editores de Wikipedia en inglés tendrían la oportunidad de dar soporte a ediciones en otros idiomas, si mantenemos la interoperabilidad entre Wikidata y Wikipedia; con todas las ediciones de Wikipedia en otros idiomas. Existen preocupaciones legítimas sobre la complejidad de la interfaz (para todos los proyectos Wiki) y los estándares de obtención de fuentes, pero abordémoslas en lugar de rechazar con carta blanca cualquier sinergia. ~ 🦝 Shushugah  (él/él •  discusión ) 23:24, 3 de octubre de 2024 (UTC) [ responder ]
Estoy familiarizado con nuestros cuadros de información que utilizan Wikidata. Sin embargo, los usos que conozco no son bidireccionalmente transparentes en la forma en que Remsense menciona, ya que es muy necesario ingresar a Wikidata para editarlos. CMD ( discusión ) 23:31 3 oct 2024 (UTC) [ responder ]

La verificabilidad no garantiza la inclusión

He comenzado un nuevo ensayo, Usuario:Cambalachero/La verificabilidad no garantiza la inclusión , en el que se enumeran casos de cosas que no deberían usarse en Wikipedia, incluso si tenemos referencias al respecto. ¿Tienes otras ideas o mejores formas de explicar las actuales? Cambalachero ( discusión ) 18:35 3 oct 2024 (UTC) [ responder ]

Podrías considerar agregar algo sobre el contenido "de la cultura popular", como se menciona en WP:IPC . Específicamente, generalmente no es apropiado incluirlo sin una fuente secundaria . DonIago ( discusión ) 19:14 3 oct 2024 (UTC) [ responder ]
Supongo que conoces WP:Onus y estás escribiendo un ensayo explicativo al respecto. Aaron Liu ( discusión ) 20:10, 3 de octubre de 2024 (UTC) [ responder ]