La sección técnica de la bomba de agua del pueblo se utiliza para discutir cuestiones técnicas sobre Wikipedia . Los informes de errores y las solicitudes de funciones deben realizarse en Phabricator (consulte cómo informar un error). Los errores con implicaciones de seguridad deben informarse de forma diferente (consulte cómo informar errores de seguridad).
Si desea informar un error de JavaScript , siga estas instrucciones . Las preguntas sobre MediaWiki en general deben publicarse en el servicio de asistencia de MediaWiki. Las discusiones se archivan automáticamente después de permanecer inactivas durante cinco días.
Cuando se cierra la sesión, en modo oscuro, en {{ Soulfly }} , el enlace real de Soulfly es de un gris extremadamente oscuro que es difícil de ver sobre un fondo negro. Antes no era así. ¿Alguien sabe cómo solucionar esto? -- Jax 0677 ( discusión ) 15:47 5 sep 2024 (UTC) [ responder ]
Gracias, supongo que tendremos que esperar nuestro turno.
El problema se soluciona cuando realmente INICIÉ SESIÓN, pero no se soluciona cuando CIERRO LA SESIÓN. -- Jax 0677 ( discusión ) 16:11 5 sep 2024 (UTC) [ responder ]
Ayer realicé esta modificación para mejorar la visualización de los enlaces propios en los cuadros de navegación. Intentaré solucionarlo por completo hoy, ya que este cuadro de navegación específico sigue apareciendo. Izno ( discusión ) 16:10 5 sep 2024 (UTC) [ responder ]
Esto debería solucionarse para esta plantilla. Izno ( discusión ) 17:37 5 sep 2024 (UTC) [ responder ]
Cargador de avisos de edición mejorado
Trabajé en un módulo que serviría como un cargador mejorado de avisos de edición para Wikipedia. Consulte testwiki:Module:Editnotice_load y Module:Editnotice load (que es una copia exacta). Las características incluyen avisos de edición por categoría, mejores avisos de grupo y avisos de edición por ID de página (lo que reduciría la necesidad de mover las páginas).
Quiero recibir más comentarios sobre este cargador antes de que se implemente inevitablemente. Consulta la wiki de pruebas. Debería ser compatible con versiones anteriores de la forma en que hacemos las cosas, pero me gustaría que se hicieran comprobaciones al respecto primero.
Si esto se quiere implementar, será necesario realizar un par de cambios, entre ellos:
Plantilla:Editnotices/Categoría/Páginas de desambiguación
¿Algo más? ¡Genial! Aasim 19:06, 9 de septiembre de 2024 (UTC) [ responder ]
Sería útil contar con alguna documentación sobre cómo funciona desde la perspectiva del usuario para comprender el contexto y cómo se usaría en la práctica, incluida la forma en que se aplican las restricciones de seguridad. Como nota al margen, no estoy seguro de que su implementación sea "inevitable". isaacl ( discusión ) 22:03, 9 de septiembre de 2024 (UTC) [ responder ]
Tengo algunos casos de prueba en testwiki. Para obtener mejores resultados, visualice el sitio cuando haya cerrado la sesión e inspeccione el HTML cuando haya iniciado sesión.
testwiki:Taylor Swift debería ser un buen ejemplo de cómo lograr que funcionen los avisos de edición de categorías. testwiki:Protected title y testwiki:Protected title2 muestran el aviso de edición de protección tanto en la pantalla de creación como en la pantalla "no existe" cuando un título está protegido contra su creación por otras razones.
testwiki:Special:EditPage/A debería mostrar el aviso de página de testwiki:Template:Editnotices/PageID/54370 (que es para A). También puedes ver que renombré los "avisos de página" anteriores a "avisos de título" porque la forma en que los avisos de página están vinculados actualmente es en realidad a los títulos, no a las páginas. El nuevo "aviso de página" seguirá vinculado a una página específica porque usa PageID. No habrá necesidad de actualizar los avisos de título para las páginas que existen. Por otro lado, para las páginas que no existen, el aviso de título deberá mantenerse actualizado. Awesome Aasim 04:01, 10 de septiembre de 2024 (UTC) [ responder ]
No puedo saber desde la página del artículo cómo usar la función: dónde se encuentra el aviso de edición, cómo se limitará el acceso, etc. Por lo tanto, es difícil evaluar la función sin saber el costo de mantenimiento. isaacl ( discusión ) 09:58, 10 de septiembre de 2024 (UTC) [ responder ]
Los avisos de edición se encuentran en el mismo pseudoespacio: Template:Editnotices/. Consulte testwiki:Module:Editnotice load/config.
También moví los enlaces de los avisos de edición a un cuadro plegable porque la cantidad de avisos de edición que se pueden crear se ha vuelto relativamente alta después de agregar avisos de categorías. Awesome Aasim 13:16, 10 de septiembre de 2024 (UTC) [ responder ]
Vale, veo que ahora hay un enlace encima del aviso de edición que indica su ubicación, de modo que los avisos basados en categorías se agrupan en una subpágina "Categoría". ¿Cuáles son las mejoras para los avisos basados en grupos? isaacl ( discusión ) 18:33 10 sep 2024 (UTC) [ responder ]
Hay menos ambigüedad en la forma en que se manejan. Por ejemplo, en testwiki:Template:A/B/C/D/E, hay cinco avisos de edición grupales diferentes que se pueden crear. Entonces, si hay una página en la que es deseable que el grupo Template:A/B necesite un aviso grupal, y Template:A/B/C necesita otro aviso grupal, y Template:A/B/D necesita otro aviso grupal, eso ahora se puede hacer; habrá un aviso grupal común y dos avisos grupales separados para las subpáginas. Awesome Aasim 19:21, 11 de septiembre de 2024 (UTC) [ responder ]
Sugeriría implementar la implementación en etapas y crear un plan de prueba para garantizar que nada retroceda. Editar tantas páginas de interfaz y plantillas totalmente protegidas a la vez parece demasiado trabajo para que un administrador se ofrezca como voluntario. Por ejemplo, la categoría específica editnotices que mencionas se puede dejar para más adelante, ya que ya tenemos un sistema decente para manejar esas categorías. Inmediatamente, en preparación para esto, consideraría agregar las siguientes plantillas de editnotices de categorías; esto no se puede hacer de inmediato, ya que también deben eliminarse de Module:Mainspace editnotice , de lo contrario, aparecerían dos veces cuando se implementen el resto de los cambios. – SD0001 ( discusión ) 08:01, 10 de septiembre de 2024 (UTC) [ responder ]
En realidad, creo que esto podría ser algo que se haría mejor de una sola vez. Eliminar los dos avisos de edición de categorías de Module:Mainspace editnotice debería ser una decisión obvia después de la implementación. La forma en que el módulo realiza actualmente estas comprobaciones, comprobando el wikitexto sin analizar, actualmente es pésima.
¿Tienes alguna idea para un ejecutor de pruebas de Scribunto para la carga del módulo Editnotice para garantizar que todo funcione con los editnotices de demostración? Awesome Aasim 16:53, 13 de septiembre de 2024 (UTC) [ responder ]
Todavía no he notado ningún error ni regresión. Si alguien pudiera volver a mirar mi código, tal vez podamos identificar posibles problemas. Awesome Aasim 12:52, 2 de octubre de 2024 (UTC) [ responder ]
¿Qué opinas sobre Docbunto?
Encontré una herramienta de autodoc poderosa en Fandom Dev Wiki llamada Docbunto, y pude hacer algunos cambios para que funcione en la Wikipedia de prueba. Creo que sería genial tener una herramienta de autodoc como Docbunto en Wikipedia para ayudar a acelerar el proceso de escritura de la documentación de los módulos. Pero la característica clave que me gusta es la capacidad de incorporar plantillas y similares en las páginas de Lua.
No creo que esté listo aún para la Wikipedia en inglés, pero tal vez con algunos cambios pueda tener muchas funciones y estar listo. Sí, no somos exactamente un repositorio de código, pero tenemos miles de módulos utilizados en artículos para los que sería útil tener documentación automática. Impresionante Aasim 18:21, 17 de septiembre de 2024 (UTC) [ responder ]
Wikcionario usa algo similar. Ver documentación de wikt:Module:module. Pero la característica clave que me gusta es la capacidad de transcluir plantillas y similares en páginas Lua. En cuanto a esto, ya podemos hacerlo en esta wiki: Módulo:Módulo wikitexto . – SD0001 ( discusión ) 20:15, 17 de septiembre de 2024 (UTC) [ responder ]
Otra mejora que podemos hacer con respecto a Wiktionary es aprovechar que ahora los números de línea se pueden vincular. Lo ideal sería que los documentos generados de las funciones exportadas incluyan enlaces a sus definiciones de código fuente. – SD0001 ( discusión ) 20:18, 17 de septiembre de 2024 (UTC) [ responder ]
En cuanto a esto, ya podemos hacerlo en esta wiki: Módulo:Texto wiki del módulo . Eso es muy confuso y no tiene mucho sentido para mí cómo funciona esto o por qué debería funcionar. Pero entonces, un módulo de autodoc que renderiza comentarios de módulo también es muy confuso, aunque menos confuso porque leer comentarios para analizar desde el módulo tiene menos probabilidades de fallar que leer variables desde el módulo de documentación después de configurarlas en "addText". Los comentarios del módulo deben aprovecharse en el analizador. Abrí una tarea (y envié mi primer parche a MediaWiki para completarlo) para que MediaWiki solo analice el contenido de los comentarios CSS y JS, consulte phab:T373834 (¡y por favor envíe más comentarios sobre cómo puedo mejorar ese parche!) Awesome Aasim 00:21, 18 de septiembre de 2024 (UTC) [ responder ]
Consideramos generar documentación desde LuaDoc al crear Scribunto, pero decidimos no hacerlo por las mismas razones por las que la mayoría de las páginas de documentación aquí están en subpáginas /doc en lugar de estar en línea en la página de plantilla: los documentos en línea no se pueden proteger por separado del módulo/plantilla y cualquier edición de los documentos en línea significa que cualquier página que use el módulo/plantilla debe volver a analizarse. Anomie ⚔ 23:50, 17 de septiembre de 2024 (UTC) [ responder ]
Me lo imagino. Creo que este documento en línea es un buen punto de partida para la mayoría de los módulos de Lua, pero en última instancia debería haber documentación adicional que vaya más allá de las funciones predeterminadas y describa exactamente qué hace el módulo. Impresionante Aasim 23:53, 17 de septiembre de 2024 (UTC) [ responder ]
Sí, sería bueno poder editar la documentación sin pasar por solicitudes de edición, aunque también lo sería generar automáticamente secciones de documentación para funciones. Nardog ( discusión ) 01:20, 18 de septiembre de 2024 (UTC) [ responder ]
El pastoreo automático de gatos no va a funcionar en Wikipedia. Imaginen obligar a cada módulo a tener comentarios en un formato fijo con información adicional para que la máquina pueda analizarlos. Johnuniq ( discusión ) 02:27 18 sep 2024 (UTC) [ responder ]
Es una práctica realmente mala no incluir comentarios en el código. Obviamente, Autodoc no funcionará si no hay comentarios con el formato adecuado. El objetivo de Autodoc es documentar funciones y variables y, lo que es más importante, las exportaciones de módulos. Incluso las funciones que utilizan otros módulos. Nunca se pretende reemplazar la página de documentación del módulo en la parte superior de cada uno; solo complementarla. Awesome Aasim 03:05, 18 de septiembre de 2024 (UTC) [ responder ]
Sí, los comentarios útiles son geniales. Lo que quise decir fue que sería muy difícil conseguir que editores independientes utilizaran un formato fijo. Además, no creo que documentar todas las funciones y variables sea posible o incluso deseable, por ejemplo, debido a la inevitable deriva entre los comentarios esperanzadores y el código real. Estoy de acuerdo en que las exportaciones deben documentarse y una vez argumenté firmemente que un módulo (ahora no recuerdo dónde) no debería tener todas las funciones exportadas debido a la confusión y los problemas de mantenimiento resultantes. Perdí ese argumento. Johnuniq ( discusión ) 03:34, 18 de septiembre de 2024 (UTC) [ responder ]
Hay algunas cosas relacionadas que se me ocurren.
En realidad, crear una lista de variables de forma automática es muy fácil. La parte difícil es obtener argumentos en bucles. Consulta:Module:Templatedata fyrir skriftu, que puede crear datos de plantilla básicos (que contienen solo una lista de variables) con el código {{#invoke:Templatedata fyrir skriftu|main|''nombre del módulo con espacio de nombres''}}.
También hay una solicitud a WMF en meta:Community_Wishlist/Wishes/Document_ALL_the_modules! sobre este mismo tema.
Pensándolo bien, parte de doc.wikimedia.org está construido sobre una lógica similar a la de docbunto. Snævar ( discusión ) 19:08 19 sep 2024 (UTC) [ responder ]
¿Por qué no ambas? Si hay comentarios en el código con un formato determinado, muéstrelos en /doc, pero también permita que se los sobrescriba o se los añada sin tener que editar el módulo directamente. Nardog ( discusión ) 03:37, 18 de septiembre de 2024 (UTC) [ responder ]
+1. Creo que tener ambos es útil. Podemos proporcionar una descripción general para el usuario final en la parte superior de la página de documentación del módulo y una descripción general para el desarrollador en la documentación automática. Algo similar a cómo implementé la documentación automática en testwiki:Module:Docbunto y testwiki:Module:i18n. Debería haber algún tipo de exención de responsabilidad que indique que la documentación se genera automáticamente y que el contenido se puede anular. Genial Aasim 14:42, 18 de septiembre de 2024 (UTC) [ responder ]
Trabajé un poco más en el módulo (en realidad no trabajé mucho) y me pregunto si el módulo se puede importar desde testwiki a Wikipedia en inglés. Es posible que tengamos que actualizar algunos de los enlaces de atribución para que apunten a los usuarios de Fandom, pero no mucho más. Awesome Aasim 01:23, 25 de septiembre de 2024 (UTC) [ responder ]
Eres el único colaborador en testwiki. Solo cópialo. Parece que has modificado Módulo:Documentación en testwiki para que muestre automáticamente los documentos generados. Puede ser más intuitivo no hacer eso y, en su lugar, hacer que las subpáginas /doc llamen al módulo autodoc (la forma en que está configurado en wikcionario), lo que permite que los documentos escritos de forma automática y manual coexistan, lo que deja más claro de dónde proviene el autodoc, evita la rareza de que aparezca un botón [crear] en el encabezado de la documentación incluso cuando la documentación aparentemente existe, etc. – SD0001 ( discusión ) 04:13, 25 de septiembre de 2024 (UTC) [ responder ]
Pero la primera edición en testwiki incluye un resumen de la edición con un enlace a la fuente. Eso debería conservarse. Las ediciones posteriores también pueden conservarse en el historial aquí. Todavía tengo dudas sobre si la documentación automática puede ser útil en Wikipedia, pero tenerla aquí permitiría demostraciones en vivo. Johnuniq ( discusión ) 05:37, 25 de septiembre de 2024 (UTC) [ responder ]
Problema: Ese módulo está en testwiki, que no aparece como una opción en Special:Import . Solo está disponible test2wiki (se agregó en febrero de 2013 cuando Scribunto apareció aquí). Una alternativa sería que Awesome Aasim duplicara la primera edición aquí, con su resumen de edición, y luego hiciera otra edición para incluir la versión actual. Johnuniq ( discusión ) 05:58, 25 de septiembre de 2024 (UTC) [ responder ]
Sí, y hay otros problemas que hacen que no esté listo para usarse de inmediato. Por ejemplo, consulta el documento automático de testwiki:Module:Documentation.
Aun así, logré incluirlo en la Wikipedia en inglés para que todos podamos trabajar juntos para hacerlo más sólido. De hecho, entiendo por qué se eliminó el módulo i18n original, mientras que el de Fandom y otros proyectos de Wikimedia no: era demasiado simple.
Creo que será necesario algún tipo de consenso para activar esto de forma predeterminada, pero al menos tenemos algo con lo que empezar. Awesome Aasim 07:00, 25 de septiembre de 2024 (UTC) [ responder ]
Tengo una pregunta. El módulo docbunto que tengo tiene una opción para "prefaciar" la documentación automática (la sección entre el encabezado y la documentación de cada función) con algún contenido. ¿Podría ese contenido ser potencialmente el material incluido en la página "/doc"? ¿O sería mejor no mezclar, para que la documentación manual no se anule con la documentación automática? Awesome Aasim 04:02, 2 de octubre de 2024 (UTC) [ responder ]
HaciendoEste guiónUn gadget en enwiki
Trabajé en este script hace años y parece que ha alcanzado un estado prácticamente estable. El script elimina la "acción=editar" de los enlaces rojos, lo que básicamente impide que el editor se cargue automáticamente al hacer clic en páginas inexistentes que uno tiene permiso para crear. Creo que esto debería estar disponible como un gadget para permitir más configuraciones. Algo como: No ingresar inmediatamente al modo de edición al hacer clic en un enlace rojo .
¿Qué opinas? Impresionante Aasim 15:29, 24 de septiembre de 2024 (UTC) [ responder ]
Es difícil entender por qué alguien querría hacerlo, incluso dejando de lado el hecho de que recorre todos los enlaces de la página cada décima de segundo. Nardog ( discusión ) 12:45 25 sep 2024 (UTC) [ responder ]
No estoy seguro de si los números en Wikipedia:User scripts/List están actualizados, pero si lo están, no parece que muchos lo hayan adoptado hasta ahora, por lo que no espero que muchos opten por participar. En general, queremos que las personas que siguen un enlace rojo inicien una página. — xaosflux Discusión 13:07, 25 de septiembre de 2024 (UTC) [ responder ]
Sí, lo sé. Esto es para que recoja enlaces en las vistas previas de VE, etc. ¡Genial! Aasim 14:12, 25 de septiembre de 2024 (UTC) [ responder ]
@ Awesome Aasim No he realizado muchos scripts en torno a VE, pero parece que debería haber una forma de agregar un detector de eventos a cosas como la ventana de vista previa de VE y solo hacer que se ejecute cuando cambia el contenido. -- Ahecht ( PAGINA DE DISCUSION) 14:52, 25 de septiembre de 2024 (UTC) [ responder ]
Hmm... No estoy seguro... tal vez alguien con más experiencia con scripts lo sepa... Impresionante Aasim 05:55, 26 de septiembre de 2024 (UTC) [ responder ]
Ni siquiera necesitarías eso; puedes simplemente adjuntar un detector onclick a los elementos "a.new" y modificar el href para eliminar &action=edit cuando se hace clic en ellos, incluso si se agregaron dinámicamente después de la carga de la página. Writ Keeper ⚇ ♔ 06:13, 26 de septiembre de 2024 (UTC) [ responder ]
¡Oh! Déjame probar esto. Un segundo. ¡Genial! Aasim 06:13, 26 de septiembre de 2024 (UTC) [ responder ]
De hecho, he cambiado de opinión. Si lo hiciera, cosas como "abrir enlace en una nueva pestaña" no funcionarían correctamente. Espero que haya algo más inteligente. Genial Aasim 06:15, 26 de septiembre de 2024 (UTC) [ responder ]
No, funciona con nuevas pestañas tan bien como cualquier otra cosa:
$ ( "#mw-content-text" ). on ( "click" , "a.new" , function ( event ){ $ ( this ). attr ( "href" , $ ( this ). attr ( "href" ). replace ( "&action=edit" , "" )); })
La modificación de la URL se produce antes del clic, por lo que si haces CTRL+clic o cualquier otra cosa para abrir una nueva pestaña, obtendrás la URL modificada. Writ Keeper ⚇ ♔ 06:22, 26 de septiembre de 2024 (UTC) [ responder ]
¿Qué pasa con los enlaces que no están en mw-content-text? Por ejemplo, las pestañas y las barras de navegación. Genial Aasim 06:24, 26 de septiembre de 2024 (UTC) [ responder ]
No estoy seguro de por qué tendrías enlaces rojos fuera de mw-content-text, pero si eso fuera una preocupación, simplemente elegirías un nodo más arriba que #mw-content-text. Writ Keeper ⚇ ♔ 06:25, 26 de septiembre de 2024 (UTC) [ responder ]
Si una página temática no tiene una página de discusión, la pestaña de la página de discusión aparece como un enlace rojo; de manera similar, si una página de discusión no tiene una página temática, la pestaña de la página temática aparece como un enlace rojo. Estas pestañas están fuera de mw-content-text. -- Red rose64 🌹 ( discusión ) 16:28 26 sep 2024 (UTC) [ responder ]
Estoy echando un vistazo a los requisitos en WP:GADGET y parece que los cumple todos:
Los gadgets deben funcionar si se incluyen sin ninguna configuración adicional. : Este script no requiere ninguna configuración.
Los gadgets deben ser compatibles con todos los navegadores principales, es decir, no deben finalizar con errores. : Acabo de comprobarlo. Funciona tanto en navegadores basados en Chromium como en Firefox.
Los gadgets deberían funcionar en la mayoría de los navegadores principales (compatibilidad entre navegadores). Las excepciones deben indicarse claramente. : Lo es. El script funciona en la mayoría de los navegadores, pero no en todos. Utiliza la biblioteca de URL, que es compatible con prácticamente todos.
La duplicación de dispositivos solo debe realizarse si es razonable. : Esto no aplica.
Las colecciones de scripts deben dividirse si tienen funciones dispares. : Esto no aplica.
Los gadgets que requieren permisos deben estar marcados y deben fallar correctamente si los permisos no están presentes. : Esto no requiere ningún permiso, ya que solo afecta el comportamiento de los enlaces rojos.
Los gadgets que solo funcionan en algunas máscaras deben marcarse como tales si esos datos están disponibles. : Irrelevante, ya que funciona en todas las máscaras, no solo en Vector y Timeless.
No veo ningún requisito que indique que el script deba tener un uso generalizado. No busco que esto esté activado de forma predeterminada. Aquellos que lo deseen pueden habilitarlo en las preferencias. Awesome Aasim 18:42, 29 de septiembre de 2024 (UTC) [ responder ]
Piense en esto: o bien se trata de informes de errores antes de encenderlo o bien de informes de errores después. ¿Está planeando solucionarlos? En ese caso, lo único que tendremos será un dispositivo sin mantenimiento. Izno ( discusión ) 19:31 29 sep 2024 (UTC) [ responder ]
El último informe de error verificado que recibí se refería a enlaces interwiki que mi script interrumpía. Eso se solucionó gracias al trabajo de Matma Rex , que implementé inmediatamente después. El siguiente se queja de que se están eliminando los enlaces "action=delete", lo que no suena bien porque esto solo afecta a los enlaces rojos. No me dieron suficiente información para averiguar dónde estaba sucediendo esto.
Definitivamente hay espacio para algunas optimizaciones, especialmente porque tener tres instrucciones en una línea no es lo ideal. Pero esas son correcciones de formato y estilo, no correcciones de funcionalidad. Awesome Aasim 19:52, 29 de septiembre de 2024 (UTC) [ responder ]
Quiero decir, personalmente, no apoyaría la incorporación de un gadget que ejecute una función de JavaScript diez veces por segundo en cada página de la wiki, especialmente para un cambio tan menor. Writ Keeper ⚇ ♔ 12:57, 2 de octubre de 2024 (UTC) [ responder ]
Yo también veo el problema. El problema es que o bien se ejecuta una vez y luego nunca funciona cuando otras cosas agregan enlaces rojos, o bien se actualiza continuamente. Probablemente haya una manera de ejecutar esta función tan pronto como se cambie el DOM, sin recurrir a un hilo establecido por setInterval. Awesome Aasim 13:02, 2 de octubre de 2024 (UTC) [ responder ]
MutationObserver suena como lo que buscas. Anomie ⚔ 23:30, 2 de octubre de 2024 (UTC) [ responder ]
¿Qué problema resuelve esto? ¿Cuál es el problema que tiene la gente con los enlaces rojos que llevan al formulario de creación? Nardog ( discusión ) 13:41 2 oct 2024 (UTC) [ responder ]
No todo el mundo quiere que cada enlace rojo abra el editor. Esto daría a las personas la opción de evitar abrir el editor al hacer clic en un enlace rojo. No creo que esto deba estar habilitado de forma predeterminada, pero sí creo que debería ser una opción. Awesome Aasim 15:23, 2 de octubre de 2024 (UTC) [ responder ]
Construyendo una calculadora de índice corporal simple
En esta página de discusión se está discutiendo la creación de una calculadora que utilice la circunferencia de la cintura y la altura como índice de la "redondez" del cuerpo , que se basa en la excentricidad y se utiliza para la evaluación antropométrica en la investigación en salud, reportada por primera vez aquí.
Existe un borrador . Se necesitan ajustes para proporcionar entradas tanto en sistema métrico como imperial, y dos puntos decimales, y cualquier dispositivo que garantice la simplicidad para el uso público. La calculadora completa se presentará en el artículo. En este sitio se puede encontrar un ejemplo comercial.
Solución audaz: una interfaz de entrada cero, sin cintura, sin altura para ingresar, pero aún así proporcionar el BRI deseado: una tabla con cintura de izquierda a derecha, altura de arriba a abajo, BRI en celdas.
Uwappa : gracias, aunque no está claro por qué se utilizan 2 entradas para la cintura y la altura, y falta el factor de excentricidad. ¿Podrías ingresar los datos y mostrar el resultado aquí? También se necesita la visualización en paralelo de los resultados métricos e imperiales con 2 decimales. Consulta un ejemplo aquí (usa el inicio de sesión de Wikipedia para acceder a la wiki médica). Zefr ( discusión ) 01:28, 26 de septiembre de 2024 (UTC) [ responder ]
La tabla se basó en su "uso de la circunferencia de la cintura y la altura como un índice de la "redondez" del cuerpo", siendo la cintura y la altura las dos entradas y la redondez la salida.
Tendrás muchas más de 2 entradas tanto para la cintura como para la altura, de ahí los tres puntos.
La MDwiki pide peso y altura, no cintura y altura. No importa, la idea sigue siendo la misma: no hay que introducir ningún dato, se hacen todos los cálculos por adelantado. No hay umbral, no se requiere ningún esfuerzo por parte de los lectores. He utilizado su enlace para crear los números para el ejemplo siguiente, que espero que sean suficientes para darle una idea de una tabla similar con cintura y altura como datos de entrada.
Una idea adicional: dar un paso más y responder la pregunta que estará en la mente del lector: ¿Estoy saludable?
Codifique por colores el fondo, desde el verde para saludable, pasando por el amarillo hasta el rojo para peligroso. Un lector podría mirar la fila cercana a su propia altura y ver respuestas a varias preguntas:
¿Mi peso/cintura está en verde, amarillo o rojo?
Si es amarillo o rojo, ¿cuál es el valor verde al que debo aspirar?
Los códigos de color que aparecen a continuación no se basan en datos reales, son solo un ejemplo.
Una propuesta aún más audaz que probablemente te haga dudar, pero de todos modos, basándome en tu pregunta sobre el sistema métrico/imperial: reserva la calculadora para los médicos y apunta al público en general mientras estés en Wikipedia. Omite atrevidamente los números en las celdas y muestra tanto el sistema métrico como el imperial en los encabezados de filas y columnas. La tabla responderá de todos modos la pregunta que tiene el lector en la mente: ¿qué cintura/peso es saludable para mí, dada mi altura?
Eso podría incluso permitir usar tanto el peso como la cintura en los encabezados de las columnas y responder dos preguntas: dada mi altura, ¿qué peso y cintura son saludables? — Comentario anterior sin firmar agregado por Uwappa ( discusión • contribuciones ) 06:49, 26 de septiembre de 2024 (UTC)[ responder ]
Estoy reinventando la rueda. Por favor, mirenPodrías hacer todos los cálculos necesarios y crear un gráfico similar para BRI. Uwappa ( discusión ) 07:24 26 sep 2024 (UTC) [ responder ]
He creado uno:Gráficos de BRI (números de colores) vs altura h vs circunferencia de cintura ccmɢʟee ⎆ τaʟκ 17:34, 29 de septiembre de 2024 (UTC) [ responder ]
En Wikivoyage, ese artículo es de una calidad mediocre. No debería haber un comienzo allí. No estoy seguro de cómo eliminarlo y qué causó el error (¿podría suceder con otros artículos?). Piotrus at Hanyang | responder aquí 04:20, 26 de septiembre de 2024 (UTC) [ responder ]
Se agregó a Wikidata en esta revisión. No estoy seguro de por qué, ya que al revisar el historial de Wikivoyage:Kaesong nunca tuvo calidad de estrella. novov discusión edits 05:58, 26 de septiembre de 2024 (UTC) [ responder ]
@ Hanyangprofessor2 : La estrella se debe a la "insignia" (una pequeña roseta) en d:Q109079#sitelinks-wikivoyage. Como se señaló anteriormente, esto fue establecido por Dexbot ( discusión · contribuciones ) hace casi diez años; tendría que preguntarle a su botop ( Ladsgroup ) cuál es el mecanismo que activó esta modificación. Si realmente está mal, estas "insignias" parecen ser editables por el usuario. -- Red rose64 🌹 ( discusión ) 15:15, 26 de septiembre de 2024 (UTC) [ responder ]
No lo son; guardar los cambios realizados en ellos está limitado a ciertos grupos de usuarios. novov talk edits 22:59, 26 de septiembre de 2024 (UTC) [ responder ]
@ Ikan Kekek Para tu información, y tal vez sepas a quién contactar. O informa esto a WV Traveller's Pub. No estoy seguro de qué tan grave es este problema, pero creo que la estrella no debería estar ahí para los artículos "utilizables". Piotrus en Hanyang | responder aquí 07:21, 27 de septiembre de 2024 (UTC) [ responder ]
No entiendo cuál es el problema. ¿Está destacado en Wikidata? Creo que lo mejor es discutirlo allí. Normalmente no edito Wikidata. Puedes plantearlo en el pub de voy:Wikivoyage:Travellers. Ikan Kekek ( discusión ) 15:35 27 sep 2024 (UTC) [ responder ]
@ Hanyangprofessor2 El bot agregó la insignia hace diez años porque al menos en ese entonces esta revisión para ser exactos tenía voy:Template:Usablecity. Tenga en cuenta que la insignia se agregó para "artículo recomendado" [1] de ahí la plata (no el oro). Hay muchas insignias. Debería poder ver la lista de páginas que tienen insignias en voy:Special:PagesWithBadges Ladsgroup overleg 10:26, 27 de septiembre de 2024 (UTC) [ responder ]
Y la versión actual de voy:Kaesong#Go next todavía tiene {{usablecity}}. Por lo tanto, este es un asunto de Wikivoyage y no es nuestro problema en absoluto. -- Red rose64 🌹 ( discusión ) 18:06 27 sep 2024 (UTC) [ responder ]
@ Ikan Kekek @ Redrose64 El problema es que los artículos utilizables en Wikivoyage son sólo artículos de nivel medio (ver voy:Wikivoyage:Estado del artículo). Una estrella debería indicar un equivalente de un artículo destacado; en Wikivoyage, ese sería un artículo de clase estrella. Un equivalente de buen artículo sería una guía (que incluso utiliza la cruz verde de GA). Tener estrellas de barn que se parezcan a artículos destacados para los artículos utilizables de Wikivoyage, que son equivalentes a nuestros artículos de clase B o C, no tiene sentido y podría decirse que es activamente engañoso. Piotrus at Hanyang | responder aquí 03:16, 30 de septiembre de 2024 (UTC) [ responder ]
PD. Y es un problema para nosotros (no para Wikivoyage), porque somos nosotros (Wikipedia en inglés) los que tenemos indicadores engañosos que sugieren que el artículo de nuestro proyecto hermano es de alta calidad, cuando no lo es. Wikivoyage ha identificado correctamente el artículo como un artículo de nivel medio (utilizable), pero lo estamos marcando incorrectamente como artículos de alto nivel. Piotrus at Hanyang | responder aquí 03:18, 30 de septiembre de 2024 (UTC) [ responder ]
PPS. Compárese con Hiroshima , que es un artículo de nivel de estrella en Wikivoyage, y está correctamente etiquetado con la estrella amarilla de ese proyecto en nuestro artículo. ¿Por qué etiquetamos los artículos utilizables de Wikivoyage y por qué usamos el símbolo de artículo destacado en lugar del círculo azul de Wikivoyage (que es el símbolo de sus artículos utilizables)? Como mínimo, el símbolo de contenido utilizable debería ser fijo (de la estrella de FA al círculo azul), y sugeriría enfáticamente eliminar cualquier símbolo para esa clase (que está por debajo del equivalente de nivel GA). Espero que el problema esté más claro ahora. Piotrus at Hanyang | responder aquí 03:21, 30 de septiembre de 2024 (UTC) [ responder ]
@ Hanyangprofessor2 : Las estrellas, discos, etc. (de cualquier color) se agregan mediante mw:Extension:WikimediaBadges según la configuración de Wikidata. Si la extensión es defectuosa, envíe un ticket a phab:. Si Wikidata tiene la configuración incorrecta, corríjala o averigüe en Wikidata por qué sus bots están usando algoritmos imperfectos. Sea cual sea el problema, no es culpa nuestra. -- Red rose64 🌹 ( discusión ) 20:14 30 sep 2024 (UTC) [ responder ]
@ Redrose64 Pero es nuestro problema y no tengo tiempo para aprender los detalles de la extensión para solucionarlo. Solo lo estoy informando aquí, para que aquellos que estén más familiarizados con el problema puedan investigarlo y solucionarlo.
Voy a avisar a los editores que hayan editado la página de extensión de mediawiki a la que haces referencia: @ MarcoAurelio @Eisheeta Piotrus en Hanyang | responder aquí 06:53, 2 de octubre de 2024 (UTC) [ responder ]
@ Hanyangprofessor2 : ¿Cómo puede ser nuestro problema cuando (a) no hay ningún fallo en la Wikipedia en inglés y (b) no hay nada que se pueda hacer en la Wikipedia en inglés para modificar la situación? En cuanto a MarcoAurelio y Eisheeta, probablemente te dirán exactamente lo que ya he dicho: que la extensión muestra una estrella según lo que esté configurado en Wikidata. ¿Has planteado alguna discusión en Wikidata o en Wikivoyage? -- Red rose64 🌹 ( discusión ) 09:47, 2 de octubre de 2024 (UTC) [ responder ]
@ Redrose64 Es nuestro problema porque mostramos información engañosa a nuestros lectores. No digo que sea culpa nuestra, no digo que sea culpa de nadie (todos somos voluntarios bien intencionados aquí), pero no es un problema de Wikivoyage o Wikidata, porque el error (que puede estar relacionado con alguna mala herramienta que usan o usaron) nos afecta a nosotros, no a ellos. Y como dije, no sé dónde más plantear este problema, y somos nosotros los que más deberíamos preocuparnos por ello, ya que nosotros (nuestros lectores) somos los más afectados. Piotrus at Hanyang | responder aquí 07:34, 3 de octubre de 2024 (UTC) [ responder ]
( editar conflicto ) @ Hanyangprofessor2 : Dos usuarios de arriba han sugerido voy:Wikivoyage:Travellers' pub; ya has publicado allí antes sobre otros asuntos, por lo que estás al tanto de su existencia. Luego está d:Wikidata:Project chat. Ahora, por favor, deja de fingir que se trata de un problema de Wikipedia en inglés cuando todo lo que estamos haciendo es reflejar datos almacenados en otro lugar. Esto es como leer en tu periódico sobre alguna situación desagradable en un país extranjero y esperar que tu quiosquero local haga algo al respecto. -- Red rose64 🌹 ( discusión ) 16:15, 3 de octubre de 2024 (UTC) [ responder ]
Como ya te expliqué, no creo que sea un problema de Wikivoyage en absoluto. De Wikidata, en menor medida (porque algunos datos están alojados allí). Pero este es principalmente nuestro problema; no importa dónde se almacenen los datos: es nuestro proyecto el que muestra información engañosa. No entiendo por qué te parece bien que nuestro sitio web muestre errores. Piotrus at Hanyang | responder aquí 03:57, 4 de octubre de 2024 (UTC) [ responder ]
Nuestro sitio web muestra millones de errores. Este es un pequeño detalle menor que de ninguna manera compromete la integridad de Wikipedia en inglés. Para citar a Jonesey95: El problema es que se usa una estrella plateada tanto para "Bueno" (segundo nivel) como para "Recomendado" (es decir, tercer nivel, el nivel inferior a Buena calidad) en la extensión. Tenga en cuenta esas palabras en la extensión . Nada de lo que Jonesey95 ha escrito demuestra que sea nuestro problema en absoluto. Jonesey95 ha reiterado, con otras palabras, información que ya se le proporcionó anteriormente en este hilo. Claro, mostramos esa pequeña estrella plateada. Pero el código para mostrar esa estrella es parte del software MediaWiki, que comparten todas las wikis de WMF. -- Red rose64 🌹 ( discusión ) 07:34, 4 de octubre de 2024 (UTC) [ responder ]
Hice un montón de investigación para ver qué podría estar pasando aquí. Hasta ahora he encontrado una página que explica que en en.WikiVoyage, tienen artículos Estrella (=en.WP FA), Guía (=en.WP GA) y Usable (¿no hay equivalente en en.WP?). Luego encontré esta solicitud de bot de octubre de 2014 en Wikidata que enumera esos mismos tres estados de artículos y solicita a Dexbot que asigne insignias en función de esos estados. La edición del bot que agregó el estado de "artículo recomendado" para en.Wikivoyage a Kaesong en Wikidata ocurrió en ese mismo período de tiempo. Hasta ahora, parece que todo está funcionando como está diseñado. Luego encontré esta página CSS, parte de la extensión mw:Extension:WikimediaBadges, que asigna imágenes de estrellas. Asigna una estrella dorada a los artículos destacados y una estrella plateada a los artículos marcados con el estado "buen artículo" o "artículo recomendado".
Hasta donde yo sé, en.WP no tiene un estado de "artículo recomendado" (no veo nada comparable en la tabla en {{ Historial de artículos }} ).
TL;DR: La etiqueta "recomendado" (es decir, de tercer nivel) junto a en.Wikivoyage en Kaesong en Wikidata parece ser correcta, según los estados utilizados en en.Wikivoyage. El problema es que se utiliza una estrella plateada tanto para "Bueno" (segundo nivel) como para "Recomendado" (es decir, de tercer nivel, el nivel inferior a Buena calidad) en la extensión.
Me parece que si un "artículo recomendado" es de tercer nivel, debería obtener una estrella de bronce (para estar en línea con el oro y la plata). Sin embargo, eso podría arruinar el color de la estrella en otras wikis de WMF. Dado que la extensión no está bien documentada (ver T212020), y no he encontrado una tabla o mapa que muestre los diferentes estados en cada sitio monitoreado, es difícil saber si cambiar "artículo recomendado" a bronce en el archivo CSS solucionaría un problema aquí pero rompería algo en otro sitio. – Jonesey95 ( discusión ) 16:07, 3 de octubre de 2024 (UTC) [ responder ]
Resulta que ya existe una solicitud de función de Phabricator en T189374 para realizar este cambio. Si alguien aquí quiere que se realice este cambio y sabe cómo cargar un cambio propuesto en gerrit/github o cualquier sitio que se utilice, es mi invitado. – Jonesey95 ( discusión ) 16:24, 3 de octubre de 2024 (UTC) [ responder ]
Pinging Krinkle y Ladsgroup , quienes han contribuido con código a esta extensión. – Jonesey95 ( discusión ) 16:29 3 oct 2024 (UTC) [ responder ]
Las insignias, según tengo entendido, pertenecen a WMDE. Póngase en contacto con el equipo de Wikidata. Ladsgroup overleg 18:01, 3 de octubre de 2024 (UTC) [ responder ]
¿Cómo? Sería útil un enlace a la página de discusión correspondiente. Considero que Wikidata es impenetrable. – Jonesey95 ( discusión ) 21:09 3 oct 2024 (UTC) [ responder ]
@ Jonesey95 : d:Wikidata:Chat del proyecto, como mencioné antes. -- Red rose64 🌹 ( discusión ) 22:50 3 oct 2024 (UTC) [ responder ]
Gracias. He publicado allí. Veremos si alguien puede ayudar desde allí. – Jonesey95 ( discusión ) 23:33, 3 de octubre de 2024 (UTC) [ responder ]
@ Jonesey95 Gracias por investigarlo y tratar de ayudar realmente, en lugar de ignorarlo. Supongo que algunos lectores de Wikipedia en inglés están confundidos, pero es probable que ni siquiera sepan (o no les importe lo suficiente) como para informar esto. Piotrus at Hanyang | responder aquí 03:55, 4 de octubre de 2024 (UTC) [ responder ]
¿Alguno de los observadores habituales (o irregulares) de VPT cree que este es un problema de Wikipedia en inglés? ¿O que no lo es? Por favor, díganlo en un sentido o en otro. -- Red rose64 🌹 ( discusión ) 07:53 4 oct 2024 (UTC) [ responder ]
Vea esto en acción en un artículo que usa esta URL especial: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Body_roundness_index?withgadget=calculator — xaosflux Talk 20:01, 26 de septiembre de 2024 (UTC) [ responder ]
Algunos comentarios:
Tal como está escrito actualmente, esto no funcionará en las aplicaciones móviles oficiales de Wikipedia ni para nadie que tenga JavaScript deshabilitado o un navegador antiguo. En mi opinión, esto necesita un mejor comportamiento de respaldo antes de habilitarse. [1] Por cierto, al verlo sin el gadget, pensé que la página estaba rota y fui a editarla.
Parece imprimir NaN si ingreso una cifra de cintura pero no una de altura: esto parece ser un error básico que debería corregirse.
Al cambiar entre el sistema métrico y el imperial se pierden los valores de formato: esto no parece una muy buena experiencia para el usuario.
Quizás debería haber una forma más clara de informar errores y algo más de contexto que lo explique: eso podría ser un caso de simplemente agregar un título.
Espero que esto sea útil.
[1] Tenga en cuenta que cualquier cosa que use un gadget de plantilla no funcionará para nadie que consuma nuestro contenido fuera de Wikipedia en inglés, por lo que es algo que debe tener en cuenta, por ejemplo, Wikiwand, aplicaciones, Google, etc. Como mínimo, creo que esto debería proporcionar algún mensaje de error que diga "Este elemento interactivo no es compatible con su dispositivo". 🐸 Jdlrobson ( discusión ) 00:44, 27 de septiembre de 2024 (UTC) [ responder ]
La mayor parte de esto ya es compatible con el dispositivo, pero se necesitaron algunos pequeños cambios en la plantilla de la página wiki específica para que funcionara. [2]. Bawolff ( discusión ) 03:41, 27 de septiembre de 2024 (UTC) [ responder ]
Algunos pensamientos más. ¡Espero que esto te sea útil!
Cuando desactivo JavaScript, el cuadro está vacío; no aparece ningún mensaje que explique que no veo algo. ¿Es intencional? Captura de pantalla.
Parece que al navegar por la página con la tecla Tab, también navegas por el formulario del widget. Esto hace que sea más difícil navegar hasta el contenido legible. Puedes agregar un tabindex=-1 para eliminarlo del orden de tabulación o asegurarte de que los editores sepan que deben marcar el párrafo principal antes del cuadro de información (esto no es un problema en dispositivos móviles, donde el párrafo principal se mueve como una solución alternativa para este gran problema).
No soy diseñador (por cierto, creo que esto se beneficiaría de algún aporte de diseño), pero, en este caso, creo que un botón de llamada a la acción aquí que cargue el widget sería más efectivo, por ejemplo, "¡Aprenda cuál es el índice de redondez de su propio cuerpo!" que, al hacer clic, carga el formulario. Imagino que una llamada a la acción de este tipo se podría generalizar en una plantilla que tenga información sobre cómo cargarse. Esto también reduciría la cantidad de bytes que agregamos a la página, ya que podría cargar el código a pedido.
Volviendo a tu pregunta original sobre cómo convertir esto en predeterminado: creo que te resultaría más fácil si pudieras basar esta decisión en datos. Creo que (al menos inicialmente) sería una buena idea instrumentar esto usando la interfaz de incremento de statsv para tener una idea del uso y confirmar tu hipótesis de que los usuarios interactuarán con dichos widgets en una página, contando las visitas a la página y algún tipo de interacción (por ejemplo, escribir un número en uno de los cuadros) y comparar los dos valores. Si habilitar este gadget estuviera condicionado a esos datos:
¿Cómo sería el éxito? ¿El 10% de las personas que leen la página interactúan? ¿El 1%? ¿El 0,1%?
¿En qué circunstancias lo considerarías un fracaso?
Creo que muy a menudo nosotros (Wikipedia) permitimos experiencias predeterminadas a través de dispositivos sin inspeccionar nuestros propios sesgos sobre lo que es útil y lo que no, y enmarcarlo de esta manera puede proporcionar un modelo para el éxito en futuros experimentos y características existentes.
Sí, el cuadro vacío es intencional. Los usuarios pueden agregar texto de respaldo personalizado en el nivel de plantilla, pero el pensamiento inicial fue que esto es una mejora del artículo pero no el contenido principal. Es poco probable que un usuario en la aplicación o sin javascript cambie solo para ver la calculadora, así que es mejor no tener nada si no podemos mostrar la calculadora. Con respecto a las pestañas, me preocuparía que deshabilitarlas pueda tener un impacto negativo en la accesibilidad. Statistics es probablemente una buena idea. Sin embargo, estoy un poco nervioso de que statsv esté siendo obsoleto y no está muy claro qué está sucediendo aquí a mediano plazo (phab:T355837), sin embargo, presumiblemente habrá algún reemplazo y posiblemente sea transparente (para referencia, principalmente para mí, ya que fue difícil de encontrar, creo que mw:Gadget kitchen: grabación de métricas es el documento apropiado) [Editar: Además, las reglas sobre qué recopilación de datos es aceptable son un poco ambiguas. Supongo que aquí querríamos rastrear si un usuario interactuó con el gadget en una página específica] Bawolff ( discusión ) 05:02 1 octubre 2024 (UTC) [ responder ]
Sin duda, tenemos una barra más baja para los gadgets predeterminados que también usan activadores de categorías que para los que no los usan. El valor predeterminado es realmente la única forma de llevar gadgets activados por categorías a los lectores. Todavía no tenemos tantos, por lo que actualmente no los ocultamos permitiendo la opción de no participar. — xaosflux Talk 15:39, 2 de octubre de 2024 (UTC) [ responder ]
Noté que en Firefox (versión 130, x64 Linux) el ancho de las entradas numéricas no parece tener en cuenta las flechas de avance , lo que provoca que, por ejemplo, una altura de tres dígitos (métrica) en el índice de redondez corporal se corte en todas las máscaras de escritorio excepto Timeless. Rummskartoffel 09:14, 29 de septiembre de 2024 (UTC) [ responder ]
El hecho de que varíe entre las distintas apariencias me sugiere que podría estar relacionado con la fuente que se utiliza. Bawolff ( discusión ) 20:31 29 sep 2024 (UTC) [ responder ]
Después de observar con más atención, parece que la diferencia es que Timeless usa una fuente de 15 px, mientras que Vector usa una fuente de 13,3 px. Esto ajusta el tamaño del cuadro de entrada para que sea diferente, pero en Firefox parece que el selector de números tiene un tamaño más constante independientemente de la fuente (en comparación con Chrome, donde el selector solo aparece al pasar el mouse sobre el elemento). Bawolff ( discusión ) 03:04, 30 de septiembre de 2024 (UTC) [ responder ]
¿Enlaces permanentes de la bomba del pueblo?
¿Hay alguna manera de proporcionar un enlace permanente a los temas de Village Pump que sobreviva al archivo del tema? Thisisnotatest ( discusión ) 00:14, 28 de septiembre de 2024 (UTC) [ responder ]
Los enlaces permanentes siempre sobreviven al archivo, ya que son enlaces a una revisión específica, por ejemplo, este es el enlace permanente a la revisión anterior a mi respuesta. — xaosflux Talk 00:24, 28 de septiembre de 2024 (UTC) [ responder ]
Esta pregunta realmente pone de relieve uno de los problemas con la organización de las páginas de discusión y cualquier otro tipo de página que intente efectivamente seguir varios temas en una sola página, particularmente cuando se utilizan con el propósito de "casos" que tienen sus propias "vidas" individuales. Cuando obtienes un enlace permanente, eso te permite ver el estado de la página en algún momento. Por lo tanto, si obtienes un enlace permanente para dicha página en algún momento, puedes ver el caso de interés en ese momento. Puedes vincular hacia adelante a la siguiente versión de esa página, pero es posible que no haya habido cambios en el caso que te interesa. Es posible que debas revisar un gran número de versiones para las cuales el caso que te interesa no haya cambiado. Para encontrarlo justo antes de que se migrara a un archivo, podrías haber involucrado cientos de versiones. Por supuesto, puedes revisar el archivo, pero podría haber habido versiones en las que se agregó contenido pero luego se eliminó, por lo que terminas teniendo que mirar numerosas versiones que no afectaron al tema que te interesa. Esto es simplemente una limitación inherente a la forma en que se administran las páginas de discusión. — Comentario anterior sin firmar añadido por Fabrickator ( discusión • contribs ) 00:42 28 sep 2024 (UTC) <diff> [ responder ]
Confirmado. Estoy buscando un enlace que siempre dirija al estado actual del tema, sin importar si el tema se ha archivado o ha tenido actualizaciones posteriores. Thisisnotatest ( discusión ) 02:45 28 sep 2024 (UTC) [ responder ]
@ Thisisnotatest : Está en vigor actualmente, pero depende de varios factores. En primer lugar, la gente siempre debe hacer enlaces al hilo utilizando Wikilinks normales (es decir, [[Wikipedia:Village pump (technical)#Village pump permalinks?]]) y no enlaces externos (es decir, [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Wikipedia:Village_pump_(technical)#Village_pump_permalinks%3F]), independientemente de la página en la que se hagan esos enlaces. En segundo lugar, la página de VP debe estar configurada para que ClueBot III la archive ( discusión · contribuciones ) (este es el caso de WP:VPM y WP:VPW , pero no de VPI, VPP, VPR o VPT, que utilizan sigmabot III en minúscula). En tercer lugar, no se deben utilizar otras formas de archivado (ya sea manual, mediante script o bot) en la página de VP. Si se cumplen todos estos requisitos, ClueBot III arreglará los enlaces internos a los hilos a medida que se archiven; consulte, por ejemplo, estas ediciones. -- Red rose64 🌹 ( discusión ) 10:02, 28 de septiembre de 2024 (UTC) [ responder ]
Si hace clic en la marca de tiempo de cualquier comentario, como el primer comentario de una sección, se copiará un enlace a ese comentario en el portapapeles. Cuando en el futuro se archive esta sección, cuando se haga clic en el enlace, MediaWiki mostrará un mensaje emergente con un enlace a la nueva ubicación del comentario en el archivo. Vea mw:Help:DiscussionTools § Enlaces permanentes a páginas de discusión para más detalles. (Si desea el enlace en formato wikitexto en lugar de una URL, puede probar mi script de usuario para copiar los enlaces de comentarios al portapapeles y ahorrarse el trabajo de ajustar la URL). isaacl ( discusión ) 05:02, 28 de septiembre de 2024 (UTC) [ responder ]
@Isaacl: Gracias, es perfecto, sobre todo porque normalmente enlazaría a mi primer comentario. Thisisnotatest ( discusión ) 06:04 28 sep 2024 (UTC) [ responder ]
Tenga en cuenta que estos enlaces son mucho más frágiles que los enlaces permanentes reales. — xaosflux Talk 09:50, 28 de septiembre de 2024 (UTC) [ responder ]
Es una compensación. Un enlace a una versión de página real no se verá afectado por ediciones posteriores, mientras que la nueva función de enlace permanente a comentarios de la página de discusión se basa en que el contenido no se elimine sin moverlo y que las firmas relevantes no se modifiquen, para obtener el beneficio de vincular a un comentario específico y que también se muestren las respuestas posteriores. isaacl ( discusión ) 17:24 28 sep 2024 (UTC) [ responder ]
No es mucho más frágil y tiene el beneficio muy útil de poder ver las respuestas al vincularse con la revisión.
De hecho, es posible crear un enlace permanente a un comentario que no dependa del comportamiento "visitar la página y ver el banner emergente si el tema se ha archivado": las páginas Special:FindComment y Special:GoToComment existen y facilitan esto. Por ejemplo, este es un enlace a este tema que siempre redireccionará inmediatamente a donde se encuentre actualmente.
(@Isaacl si querías usarlos en el script mencionado anteriormente, no dudes en hacerlo; deberían ser estables. Solo necesitas el ID del fragmento del enlace que copias a través de la marca de tiempo). DLynch (WMF) ( discusión ) 19:35, 2 de octubre de 2024 (UTC) [ responder ]
¡Gracias por la información! Lo pensaré. Por un lado, me gusta tener el nombre de la página original en el enlace, de modo que quienes puedan ver el enlace al pasar el cursor sobre él obtengan una vista previa rápida de hacia dónde se dirige el enlace. Por otro lado, omitir el banner emergente es genial para llegar directamente a donde quieres ir. isaacl ( discusión ) 21:09, 2 de octubre de 2024 (UTC) [ responder ]
He actualizado mi script para generar un enlace permanente Special:GoToComment y copiarlo al portapapeles. En realidad, estoy recuperando los identificadores de los <span>elementos con un data-mw-comment-startatributo. Hay un <span data-mw-comment-start id="...">...</span>elemento anidado dentro del <h2>elemento para el encabezado; ¿se trata de algo destinado a proporcionar enlaces permanentes a los encabezados de sección? Parece funcionar con la página Special:GoToComment. isaacl ( discusión ) 22:03, 2 de octubre de 2024 (UTC) [ responder ]
Sí, si ya estás viendo los datos en el DOM, entonces también puedes usar el ID del encabezado. Es un poco menos confiable, porque no incluye el nombre de usuario de la persona que lo publicó, por lo que técnicamente es más posible que haya una colisión en la que se publique exactamente el mismo encabezado en el mismo momento exacto en varias páginas.
La principal diferencia práctica para usted podría ser estética: el punto destacado cuando sigue el enlace termina en el encabezado en lugar de en el primer comentario completo. DLynch (WMF) ( discusión ) 22:28 2 oct 2024 (UTC) [ responder ]
Hasta ahora he utilizado el enlace a un comentario individual o el enlace al encabezado utilizando el ID de la tabla de contenidos (que mi script también proporciona una forma rápida de copiar en formato wikilink). Realmente no sabía qué hacer con el ID sobre el que te pregunté. ¡Gracias por la información al respecto! isaacl ( discusión ) 22:54, 2 de octubre de 2024 (UTC) [ responder ]
Problema de vista previa
Monobook, Edge, Win11. Gadget de ventanas emergentes de navegación. Cuando apunto el mouse hacia Jon Anderson , en lugar de la vista previa esperada, veo }}. DuncanHill ( discusión ) 01:18 28 sep 2024 (UTC) [ responder ]
Para que conste, parece estar relacionado con el caso en que el cuadro de información se complica con un módulo que carga otro cuadro en el primer cuadro de información. Probablemente, está más allá de la capacidad de las ventanas emergentes para mostrar esa profundidad. — xaosflux Talk 10:12, 28 de septiembre de 2024 (UTC) [ responder ]
En window.popupPreviewFirstParOnly = false;la consola del navegador veo }}y debajo el párrafo de apertura. Las ventanas emergentes aparentemente malinterpretan el cuadro de información complicado como un párrafo de apertura que solo contiene }}. {{y }}están correctamente equilibradas en el artículo. PrimeHunter ( discusión ) 11:56, 28 de septiembre de 2024 (UTC) [ responder ]
Los nuevos usuarios ahora incluyen enlaces azules a las páginas de contribuciones de todos
Navegador Safari de iOS: NewUsers parece haber tenido un cambio recientemente, de modo que todas las páginas de contribuciones de los usuarios tienen un vínculo azul, ya sea que hayan realizado una edición o no. Preveo que esto aumentará los informes de UAA que reciben una respuesta de "Esperar hasta que el usuario edite" . ¿Hay alguna forma de evitar esto? MM (Dame información.) (Victorias) 14:45, 28 de septiembre de 2024 (UTC) [ responder ]
¿Puedes ser más específico sobre la página a la que haces referencia? El registro de creación de usuarios no parece estar haciendo esto en un par de vistas diferentes que probé. — xaosflux Talk 15:05, 28 de septiembre de 2024 (UTC) [ responder ]
Bueno, por ejemplo.
16:22, 28 de septiembre de 2024 Se creó la cuenta de usuario Karen8907 discusión contribuciones
Antes, las contribuciones aparecían en rojo si el usuario no había realizado modificaciones. Ahora, todas aparecen en azul, independientemente de si se han realizado modificaciones o no. ¿Tiene más sentido?
Tengo activado el "modo avanzado". ¿Es posible que eso tenga algo que ver? MM (Dame información). (Victorias) 15:24, 28 de septiembre de 2024 (UTC) [ responder ]
Cuando no estoy conectado, en la vista móvil, solo veo enlaces de contribuciones en azul; en la vista de escritorio, la mayoría son rojos. Por lo tanto, el "modo avanzado" (sea lo que sea) no es un factor. -- Red rose64 🌹 ( discusión ) 16:02, 28 de septiembre de 2024 (UTC) [ responder ]
Si el usuario no tiene ediciones, entonces el enlace de contribuciones tiene la clase mw-usertoollinks-contribs-no-editstanto en la versión de escritorio (probada en Vector legacy) como en la versión móvil, pero solo la versión de escritorio tiene este CSS:
. mw-usertoollinks-contribs-no-edits { color : #ba0000 ; }
Puede agregar lo siguiente a su CSS para obtener enlaces rojos en todas las máscaras asumiendo que agregan la clase:
. mw-usertoollinks-contribs-no-edits { color : #ba0000 !important ; }
El código ha funcionado. Muchas gracias, Prime. MM (Dame información). (Victorias) 16:57, 28 de septiembre de 2024 (UTC) [ responder ]
WMF cambió recientemente los colores de los enlaces en Minerva y sospecho que se trata de otra víctima (o era un delta que siempre existió y no debería haber existido). @ Jon (WMF) Izno ( discusión ) 16:48, 28 de septiembre de 2024 (UTC) [ responder ]
Solo para avisarte, mi skin es Vector (2022), no MinervaNeue. MM (Dame información.) (Victorias) 16:59, 28 de septiembre de 2024 (UTC) [ responder ]
Has vinculado el sitio móvil arriba y afirmas que estás en iOS. Hoy no puedes seleccionar un skin para el sitio móvil: siempre estás en Minerva. Izno ( discusión ) 17:08, 28 de septiembre de 2024 (UTC) [ responder ]
Fue xaosflux quien vinculó el móvil, pero probablemente MM esté allí. El "modo avanzado" es una característica de la versión móvil en https://en.m.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Special:MobileOptions. Los dispositivos móviles suelen elegir la versión móvil de forma predeterminada independientemente de su diseño. Puede cambiar en "Escritorio" o "Vista móvil" en la parte inferior de las páginas. Si dice "Escritorio", entonces actualmente está en el móvil, también llamado Minerva. PrimeHunter ( discusión ) 17:15 28 sep 2024 (UTC) [ responder ]
Sí, realmente necesitan arreglar todos esos errores de enlaces nuevos. QuicoleJR ( discusión ) 13:23 29 sep 2024 (UTC) [ responder ]
Y efectivamente, el CSS que debería estar activándose es
. mw-usertoollinks-contribs-no-edits { color : var ( --color-destructive , #d73333 ); }
Y que en cambio está siendo anulado por
a : no ([ rol = "botón" ]) : no ( . minerva__tab-text ) { color : var ( --color-progressive , #36c ); radio del borde : 2 px ; decoración del texto : ninguna ; }
Probablemente se deba a la especificidad, ya que :not()se suma a la especificidad. Izno ( discusión ) 17:11 28 sep 2024 (UTC) [ responder ]
@ Izno Tienes razón, esos estilos fueron la causa de este problema. Hemos actualizado esos estilos el viernes pasado e implementaremos la solución esta semana . EDITAR: Hablé demasiado pronto, esa actualización no solucionó el problema. He capturado esto en una tarea de Pabricator: [Minerva] Las listas de usuarios muestran el enlace azul "contribuciones" para los usuarios sin contribuciones y estamos trabajando en una solución. JDrewniak (WMF) ( discusión ) 22:04, 30 de septiembre de 2024 (UTC) [ responder ]
Las páginas de discusión y yo no nos llevamos bien
Si abro un nuevo tema en una charla (como acabo de hacer aquí), el software no me deja abandonarlo. Quiere que lo termine. Por ejemplo, supongamos que ahora mismo decido "bueno, este no es el lugar adecuado" y abandono la página descartando mi trabajo (o deseando hacerlo). Bueno, si vuelvo a esta página mañana, no me deja empezar un nuevo hilo, ni editar un hilo existente, ni siquiera leer la página . No. Es como "Ayer empezaste un hilo. ¡Te llevaré allí ahora! TERMINALO Y PUBLÍCALO, amigo, y luego podemos hablar sobre lo que te permitiré hacer a continuación".
Tenga en cuenta que esto es después de haber hecho clic en "Aceptar" en el cuadro "¿Desea abandonar esta página? Su trabajo se perderá" (que genera Firefox, no Wikipedia). Ahí está de nuevo cuando vuelvo. Puedo borrar el texto, pero no puedo borrar por completo el título ("¡No puede tener un título en blanco!") ni eliminar el hilo. Supongo que si me muriera, comenzaría a acosar a mi familia para que terminara la publicación, no lo sé.
Esto no es bueno. ¿Se puede arreglar? ¿Hay alguna solución alternativa? Sería mejor arreglarlo, ya que eso significaría que los futuros editores no tendrían que subirse a las cortinas. Gracias. Herostratus ( discusión ) 17:34 28 sep 2024 (UTC) [ responder ]
Haga clic en cancelar en lugar de vaciar el contenido. Sjoerd de Bruin (discusión) 20:36 28 sep 2024 (UTC) [ responder ]
Uf, no lo había visto y está ahí mismo. Mi error. Perdón por molestarte y gracias por el aviso. Herostratus ( discusión ) 20:52 28 sep 2024 (UTC) [ responder ]
Cuadro de vista previa
El cuadro amarillo que dice Esto es solo una vista previa; ¡tus cambios aún no se han guardado! cuando obtienes una vista previa de tu edición no parece aparecer. En cambio, el mensaje solo se muestra en texto sin formato debajo del encabezado "Vista previa", lo que hace que parezca que es parte del texto real. ¿Fue este un cambio intencional? El cuadro aparece normalmente cuando se cierra la sesión. InfiniteNexus ( discusión ) 18:52 28 sep 2024 (UTC) [ responder ]
A mí me funciona ¿Cuál es tu skin y navegador? -- Red rose64 🌹 ( discusión ) 20:26 28 sep 2024 (UTC) [ responder ]
Vector 2010 en Chrome. Pero obtengo el mismo resultado cuando intento cambiar a Vector 2022 y Firefox. InfiniteNexus ( discusión ) 06:46 29 sep 2024 (UTC) [ responder ]
¿Estás usando la función de vista previa en vivo no predeterminada? Si es así, hay una solución para el tren actual (no tengo el error a mano). 🐸 Jdlrobson ( discusión ) 18:42, 1 de octubre de 2024 (UTC) [ responder ]
No estoy seguro de a qué te refieres exactamente, pero creo que he identificado el problema. Cuando desmarco la opción "Mostrar vista previa sin recargar la página" en Special:Preferences , el cuadro aparece de forma normal. Vuelve a activarlo y el cuadro desaparece. InfiniteNexus ( discusión ) 07:22 2 oct 2024 (UTC) [ responder ]
La herramienta copyvio de Earwigs no funciona
Lo que dice en la lata. Earwig es consciente de ello. Siempre que alguien intenta utilizar la herramienta, recibe este mensaje la mayoría de las veces: Se produjo un error al utilizar el motor de búsqueda (Error de Google: Error HTTP 429: Demasiadas solicitudes). Nota: existe un límite diario en la cantidad de consultas de búsqueda que la herramienta puede realizar. Puede repetir la comprobación sin utilizar el motor de búsqueda.
Obviamente, hay un poco de tontería en torno a alcanzar el límite, que aparentemente es compartida por todos los usuarios de Wikipedia. Hubo una discusión en la sección de la bomba de WMF hace unas semanas sobre lo que la WMF puede hacer al respecto. Estoy principalmente interesado en lo que podemos hacer mientras se soluciona. Sueño con caballos (Huellas de pezuñas) (Relincha hacia mí) 00:56, 29 de septiembre de 2024 (UTC) [ responder ]
Podrías hacer tu propia búsqueda en el motor de búsqueda para encontrar fragmentos de texto del artículo. Una oración de cada párrafo debería dar una indicación de los problemas. Y puedes marcar la casilla de la herramienta para limitar la verificación. Graeme Bartlett ( discusión ) 05:49 29 sep 2024 (UTC) [ responder ]
Este es el mensaje que recibo cada vez que intento usar la herramienta de verificación Earwig desde principios de 2024. Siempre supera el límite. Le pregunté a Earwig sobre esto varias veces y creo que el problema es que los bots pueden usarlo y están haciendo que alcance su límite diario bastante temprano en el día. Desearía que los bots pudieran ser eliminados para que los editores habituales tuvieran acceso a la herramienta, pero aún no he visto ningún cambio. Ya ni siquiera intento usarla. L iz ¡Lee! ¡Habla! 22:43, 29 de septiembre de 2024 (UTC) [ responder ]
A mí me funciona con bastante frecuencia, probablemente porque estoy en una zona horaria diferente. Es posible que tengas que esperar a que termine el "día" y volver a intentarlo. Graeme Bartlett ( discusión ) 22:47 29 sep 2024 (UTC) [ responder ]
@ Liz : Hay un mensaje de Chlod que dice que la gente adecuada está al tanto y está trabajando en una forma de autenticar. Estoy segura de que eso expulsará a los bots.
¿Quizás el bot detrás de esta herramienta sea lo que está agotando a Google? No lo sé/ https://meta.wikimedia.org/wiki/Wikipedia:Village_pump_(technical)/CopyPatrol También usa Turnitin, y puedes marcar esa casilla en Earwig. Pero sus hallazgos muestran menos que la búsqueda de Google. Graeme Bartlett ( discusión ) 06:07 2 oct 2024 (UTC) [ responder ]
Hay documentación que indica que un bot está revisando los cambios recientes y marcando los casos de derechos de autor probables para copypatrol. Al mirar una sola página, que aparezcan resultados para esa página de esa manera, se genera menos tráfico que permitir que varios usuarios consulten esa misma página. Yo diría que Copypatrol debería usarse para la Wikipedia en inglés y otros proyectos compatibles, pero la herramienta earwigs cuando Copypatrol no es compatible con el proyecto. Snævar ( discusión ) 01:15, 3 de octubre de 2024 (UTC) [ responder ]
@ Graeme Bartlett y @ Snævar : CopyPatrol usa TurnItIn, no Google (a diferencia de Earwig, que usa tanto Google como TurnItIn). Probablemente por eso muestra menos (lo cual es un pequeño problema), pero quizás sea una medida provisional. Mi principal preocupación sobre CopyPatrol es que es más útil para ediciones individuales y no para un artículo completo. Sueño con caballos (Huellas de cascos) (Relincha hacia mí) 22:07, 3 de octubre de 2024 (UTC) [ responder ]
Un encabezado que comienza con un comentario wiki elimina los botones de "edición" de la interfaz de MediaWiki para esa sección
Se muestra en testwiki:Sandbox/Section edit button . Observe que en 2 de las 6 secciones faltan deliberadamente los botones "editar código fuente" o "editar" cuando se antepone un comentario wiki al texto del encabezado de una sección (consulte el código fuente de la página). Sin embargo, un comentario wiki después de un encabezado en la misma línea funciona.
Tuve que hacer una edición Special:Diff/1248413109 aquí en en.wiki para solucionar este comportamiento de MediaWiki y restaurar el botón de interfaz mencionado. La falta de botones de edición de la interfaz en las secciones puede interpretarse erróneamente como una página protegida, en particular para un usuario no registrado.
¿Es este un comportamiento intencional de MediaWiki? No informé ni busqué ningún error en Phabricator, no tengo una cuenta. 84.250.15.152 ( discusión ) 11:26 29 sep 2024 (UTC) [ responder ]
¿Algunos enlaces de Wayback Machine/Internet Archive ahora fallan?
Estaba haciendo algo de limpieza sobre el tiroteo de Lockheed Martin y me encontré con una situación que nunca antes había encontrado. Los enlaces de Internet Archive, al menos en este artículo, ahora parecen estar fallando. Cuando fui a las URL guardadas, el contenido que se había guardado en el pasado apareció de pasada, pero luego apareció un enlace diferente/contenido usurpado para widgetbox(punto)com/tomó el control. ¿Alguien más se ha encontrado con un problema similar? ¿Se trata solo de artículos de noticias de The Meridian Star ? Y bueno, para cualquiera de los que miran por aquí que saben qué es qué, etc., disculpas de antemano si posiblemente he publicado este problema en el lugar equivocado, simplemente no pude averiguar dónde podría pertenecer. Sin sarcasmo, por favor, solo pensé que sería mejor preguntar en algún lugar por aquí. - Gracias, Shearonink ( discusión ) 18:02, 29 de septiembre de 2024 (UTC) [ responder ]
Shearonink , ¿te refieres a esto? — Qwerfjkl talk 19:51, 29 de septiembre de 2024 (UTC) [ responder ]
Suceden un par de cosas.
Cuando hago clic en el enlace que publicaste arriba, obtengo un resultado que dice "la página no existe..."
PERO cuando hago clic en Ref #7/"Tres años después" en el tiroteo de Lockheed Martin desde el Meridian Star ->>https://web.archive.org/web/20120314014942/http://meridianstar.com/local/x681061768/Lockheed-Martin-Three-years-later?keyword=leadpicturestory obtengo ESTE extraño resultado de "widgetserver"-->>>https://web.archive.org/web/20120327105127/http://cdn.widgetserver.com/
Espero haberlo explicado... Estoy un poco desconcertado por todo esto. Incluso intenté hacer una búsqueda de los dos artículos de Meridian Star en Newspapers.com y también en el sitio web del periódico, pero no obtuve ningún resultado. - Shearonink ( discusión ) 22:04 29 sep 2024 (UTC) [ responder ]
Parece que un widget incluido en la página fuerza una redirección por algún motivo. De todos modos, he cambiado la referencia para usar un archivo de una fecha diferente, que no parece tener ese problema. -- Chris 08:22, 30 de septiembre de 2024 (UTC) [ responder ]
Gracias Chris G. Nunca había visto una redirección como esa, básicamente escondida dentro de una URL de Webarchive. Parece una usurpación... Eliminaré la plantilla de enlace inactivo. Estaba pensando vagamente que tenía algo que ver con las noticias recientes sobre la demanda contra Wayback Machine... - Shearonink ( discusión ) 14:33 30 sep 2024 (UTC) [ responder ]
Wayback Machine en sí @ Shearonink no fue relevante en la demanda. Más bien, se demandó a Internet Archive por su programa de préstamo de libros, por lo que no tiene ninguna relación. Según las discusiones anteriores, los límites de velocidad son un problema con el propio Google. ~ 🦝 Shushugah (él/él • discusión ) 22:12, 3 de octubre de 2024 (UTC) [ responder ]
¿Cambios relacionados rotos?
"Cambios relacionados" parece estar roto. Normalmente veo CAT:RFU usando RelatedChanges, como este. Solo obtengo los cambios del día actual. Esto es nuevo a partir de hoy. --jpgordon 𝄢𝄆𝄐𝄇 18:12, 29 de septiembre de 2024 (UTC) [ responder ]
Veo entradas desde el 22 de septiembre. En la parte superior derecha hay un cuadro que dice "500 cambios, 7 días" para mí. ¿Tienes un cuadro así? ¿Qué dice? ¿Puedes cambiarlo? PrimeHunter ( discusión ) 20:22 29 sep 2024 (UTC) [ responder ]
Parece que se ha resuelto por sí solo. --jpgordon 𝄢𝄆𝄐𝄇 14:50, 30 de septiembre de 2024 (UTC) [ responder ]
El título en cursiva no funciona en Mickey Maguire (Desvergonzado), DISPLAYTITLE hace
{{ italic title }} omite la cursiva entre paréntesis, también cuando |string=se usa. Creo que debería cambiarse, pero así es como funciona ahora. {{ Italic disambiguation }} se puede usar para su propósito sin parámetros. PrimeHunter ( discusión ) 20:13 29 sep 2024 (UTC) [ responder ]
Alternativamente, cambiar el título de la página por la definición más general de "carácter" elimina la necesidad de usar cursiva en el título. Izno ( discusión ) 20:28 29 sep 2024 (UTC) [ responder ]
¡D'oh! Acabo de darme cuenta de que debería haber usado |all=yes.
Sé que técnicamente esta área no está bajo el control de Wikipedia, pero me preguntaba si alguien sabía por qué Quarry no funcionaba. No puedo cargar ninguna de mis páginas habituales. Y, por desgracia, Phab no acepta la contraseña que suelo utilizar y no quiero restablecerla hasta el final del día, por lo que no puedo enviar un informe de error. Pero hice una búsqueda y no veo que nadie más haya enviado un ticket.
El mensaje que recibo es un logotipo de Wikimedia Cloud Services y luego:
Error
No se puede acceder a este servicio web. Póngase en contacto con un responsable de este proyecto.
Los mantenedores pueden encontrar instrucciones para la solución de problemas en nuestra documentación en Wikitech.
Intenté encontrar una página de discusión en MediaWiki, pero no tuve éxito. ¿Alguna pista? Si los servicios en la nube están inactivos, parece que afectaría a otros aspectos de este proyecto, pero estoy teniendo problemas con Quarry. Gracias. L iz ¡Lee! ¡ Habla! 22:48, 29 de septiembre de 2024 (UTC) [ responder ]
@ Taavi : ¿podría esto estar relacionado con los cambios de phab:T361471? – 2804:F14:80A0:C01:CAC:C72A:E92:375B (discusión) 01:05 30 sep 2024 (UTC) [ responder ]
Gracias por proporcionar esto. Pero es de hace meses, así que no estoy seguro de si es relevante para el problema de hoy. Sin embargo, Quarry se usa mucho, así que me sorprende que no haya un ticket abierto. Pero agradezco que busques uno relacionado. L iz ¡Lee! ¡Habla! 02:58, 30 de septiembre de 2024 (UTC) [ responder ]
El cambio que hicieron para solucionar este problema se aplicó el día 25 de este mes, por eso pensé que podría estar relacionado. En cualquier caso, Taavi es quien hizo esa corrección, por lo que lo sabría con certeza y probablemente también pueda ofrecer algo de información sobre el problema actual. – 2804:F1...92:375B (discusión) 03:43 30 sep 2024 (UTC) [ responder ]
Finalmente obtuve la contraseña correcta y envié un ticket. Aún no hay respuesta. L iz ¡Lee! ¡Habla! 05:24, 30 de septiembre de 2024 (UTC) [ responder ]
Probablemente no tenga relación. Taavi ( ¡discusión! ) 07:55, 30 de septiembre de 2024 (UTC) [ responder ]
Debería estar funcionando nuevamente, aún no estoy seguro de por qué falló, estoy investigando en phab:T375997. DCaro (WMF) (discusión) 08:03 30 sep 2024 (UTC) [ responder ]
Gracias por comprobarlo, Taavi y DCaro (WMF) . ¡ Lee ! ¡ Habla! 21:27, 30 de septiembre de 2024 (UTC) [ responder ]
No puedo cerrar mapas (Firefox 130, Windows 10)
Seguimiento en la tarea T376391 de Phabricator
Hola a todos, últimamente he tenido un problema en el que no puedo cerrar los mapas de pantalla completa cuando hago clic en ellos en los artículos. ¿Alguna idea? No puedo hacer clic en la cruz y no puedo usar la tecla escape, literalmente la única forma de volver al artículo es refrescándolo. Probado en el modo seguro de Firefox sin extensiones. Funciona bien en Chrome. Y también, puedo cerrar mapas en Wikivoyage, específicamente mapas GPX, en lugar de GeoJSON como en Wikipedia. </ MarkiPoli > < talk />< cont /> 13:25, 30 de septiembre de 2024 (UTC) [ responder ]
He notado esto ocasionalmente también en Chrome, pero nunca he encontrado una forma consistente de reproducirlo. el wub "?!" 11:59, 1 de octubre de 2024 (UTC) [ responder ]
Creo que lo he encontrado (o al menos uno de ellos):
¿Qué artículo usaste para realizar estos pasos? Pude reproducir estos pasos (solo en Firefox, * no en Chrome ) en el artículo Puente de Brooklyn , ni siquiera necesité el segundo paso. Aunque el error solo ocurre si no abrí el mapa y lo cerré antes de abrir una imagen. – 2804:F1...ED:16CD ( discusión ) 02:43 2 oct 2024 (UTC) *editado 03:48 2 oct 2024 (UTC) [ responder ]
He investigado algunos (digo algunos porque esto parece más bien una descripción general de la causa, aunque vi que sucedía con el depurador del navegador):
La extensión Media Viewer agrega un nuevo controlador de ruta para determinar qué función llamar cuando la página navega a un hash vacío como//en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Wikipedia:Village_pump_(technical)#
Lamentablemente, el botón para cerrar el mapa de Kartographer es un elemento de anclaje html (<a>) a un hash vacío (#), y espera que se llame a esta función cuando ocurre esa navegación a un hash vacío.
Entonces, presumiblemente, si el Media Viewer configura su controlador de ruta primero (cuando abre una imagen), eso es lo que se llama cuando se hace clic en el botón de cierre de Kartographer, y no se cierra, pero si abre el mapa de Kartographer primero, configura su propio controlador que lo cierra correctamente. – 2804:F1...ED:16CD ( discusión ) 04:10, 2 de octubre de 2024 (UTC) [ responder ]
Hmmmmm, intrigante. Sin embargo, a veces he estado en una página y no he hecho clic en ninguna imagen antes de hacer clic en un mapa. ¿Alguien podría crear un ticket de Phabricator? No lo he usado antes. </ MarkiPoli > < talk />< cont /> 11:09, 2 de octubre de 2024 (UTC) [ responder ]
Esta página necesita una revisión, ya que ha sido editada con frecuencia recientemente a raíz de Helene, y la mayoría de las ediciones no fueron constructivas o incluso fueron vandalismo absoluto. He hecho varios intentos infructuosos de solicitar una mayor protección. Es posible que haya intentado utilizar un portal de solicitudes obsoleto, pero por alguna razón la información que he proporcionado en el formulario no se "acepta". -- HelpMyUnbelief ( discusión ) 20:18 30 sep 2024 (UTC) [ responder ]
¿Qué es el portal/formulario? Nardog ( discusión ) 20:22 30 sep 2024 (UTC) [ responder ]
Había seguido un enlace de un resultado de búsqueda de Google, pero lamentablemente no recuerdo con certeza cómo formulé mi consulta. Lo mejor que recuerdo es que era "solicitar protección de página site:en.wikipedia.org"; esto me dirigió ahora mismo a Wikipedia:Solicitudes de protección de página/Aumentar/Formulario, que funcionó bien. Estoy dispuesto a marcar el problema como "autocorregido". :-) — HelpMyUnbelief ( discusión ) 04:55, 2 de octubre de 2024 (UTC) [ responder ]
Necesitamos repensar el derecho de usuario confirmado extendido.
O bien se puede establecer un derecho de usuario que se otorgue solo a personas de confianza sin ningún derecho adicional asociado (y con un nivel de protección correspondiente) o se puede hacer que la confirmación extendida se otorgue manualmente. Hay demasiadas personas que juegan con el sistema para ser imbéciles odiosos en las páginas de usuario de los editores o para imponer un punto de vista en los CTOP. Liliana UwU ( discusión / contribuciones ) 21:59, 30 de septiembre de 2024 (UTC) [ responder ]
Esa es más una pregunta de tipo política/propuesta, no técnica. Izno ( discusión ) 22:01 30 sep 2024 (UTC) [ responder ]
@ LilianaUwU No necesitas tener confirmación extendida para editar la página de usuario de otra persona. Puedes hacerlo sin iniciar sesión. Créeme. Lo sé. Mi página de usuario fue vandalizada repetidamente antes de que la cerraran de forma semiindefinida. Sueño con caballos (Huellas de pezuñas) (Relincha hacia mí) 22:01, 3 de octubre de 2024 (UTC) [ responder ]
Estoy hablando de mi propia página de usuario, que está en formato ECP y, sin embargo, recibe jugadores todo el tiempo. Liliana UwU ( discusión / contribuciones ) 23:08, 3 de octubre de 2024 (UTC) [ responder ]
No puede haber tantos, según Wikipedia: Niveles de acceso de usuario Solo hay 72.041 usuarios confirmados extendidos en total. Compárelo con los 2,38 millones de usuarios confirmados automáticamente y ya parece un estándar bastante severo. En términos de los pocos idiotas odiosos que juegan con el sistema... Sea cual sea el sistema, lo van a jugar/abusar de él, pero eso no significa que no deberíamos intentar complicarnos la vida. En el aspecto técnico, podríamos llegar a un año y 1.000 ediciones sin demasiadas interrupciones, eso es probablemente suficiente para mantener a raya a los idiotas. Horse Eye's Back ( discusión ) 22:11 3 oct 2024 (UTC) [ responder ]
Noticias tecnológicas: 2024-40
Últimas novedades tecnológicas de la comunidad técnica de Wikimedia. Por favor, informe a otros usuarios sobre estos cambios. No todos los cambios le afectarán. Hay traducciones disponibles.
Actualizaciones para editores
Los lectores de 42 wikis más ahora pueden usar el modo oscuro. Si la opción aún no está disponible para los usuarios que no han iniciado sesión en su wiki, es probable que se deba a que muchas plantillas aún no se muestran bien en el modo oscuro. Utilice la herramienta de verificación del modo oscuro si está interesado en ayudar a reducir la cantidad de problemas. La página de recomendaciones brinda orientación al respecto. El modo oscuro se habilita en wikis adicionales una vez al mes.
Los editores que utilicen el editor de wikitexto de 2010 como predeterminado pueden acceder a las funciones del editor de wikitexto de 2017 agregando ?veaction=editsourcea la URL. Si desea habilitar el editor de wikitexto de 2017 como predeterminado, puede configurarlo en sus preferencias . [3]
Para los lectores que no han iniciado sesión y utilizan la interfaz Vector 2022, el enlace "donar" se ha movido de un menú desplegable junto al área de contenido a un menú superior más destacado, junto a "Crear una cuenta". Esto restablece el nivel de prominencia del enlace que tenía en la interfaz Vector 2010. Obtenga más información sobre los cambios relacionados con las experiencias de los donantes. [4]
La extensión CampaignEvents proporciona herramientas para que los organizadores gestionen eventos, se comuniquen con los participantes y promuevan sus eventos en las wikis de manera más sencilla. La extensión se ha habilitado en Wikipedia en árabe, Wikipedia en igbo, Wikipedia en suajili y Meta-Wiki. Wikipedia en chino ha decidido habilitar la extensión y se están llevando a cabo debates sobre la extensión en Wikipedia en español y en Wikidata. Para obtener información sobre cómo habilitar la extensión en su wiki, puede visitar la página CampaignEvents en Meta-Wiki.
Ver las 22 tareas enviadas por la comunidad que se resolvieron la semana pasada.
Actualizaciones para colaboradores técnicos
Los desarrolladores con una cuenta en Wikitech-wiki deben comprobar si es necesario realizar alguna acción en sus cuentas. Se están realizando cambios en la wiki para utilizar el sistema de inicio de sesión de usuario único (SUL) y otros cambios de configuración. Este cambio ayudará a reducir la complejidad general de las actualizaciones de software semanales en todas nuestras wikis.
A fondo
El cambio de servidor se completó con éxito la semana pasada con un tiempo de solo lectura de solo 2 minutos y 46 segundos. Este proceso periódico garantiza que los ingenieros puedan cambiar de centro de datos y mantener todas las wikis disponibles para los lectores, incluso si hay problemas técnicos importantes. También les da a los ingenieros la oportunidad de realizar tareas de mantenimiento y actualizaciones en sistemas que normalmente funcionan las 24 horas del día y, a menudo, ayuda a revelar debilidades en la infraestructura. El proceso involucra docenas de servicios de software y cientos de servidores de hardware, y requiere que varios equipos trabajen juntos. El trabajo realizado durante los últimos años ha reducido el tiempo de 17 minutos a 2 o 3 minutos. [5]
Reuniones y eventos
4 al 6 de octubre: Hackathon de la Conferencia WikiIndaba en Johannesburgo, Sudáfrica
Del 4 al 6 de noviembre: Conferencia de usuarios y desarrolladores de MediaWiki de otoño de 2024 en Viena, Austria
Noticias tecnológicas preparadas por escritores de Tech News y publicadas por bot • Contribuir • Traducir • Obtener ayuda • Dar retroalimentación • Suscribirse o cancelar la suscripción.
Desde ayer parece que he perdido la opción de eliminar. Hasta donde puedo ver, nada ha cambiado en cuanto a mis derechos o preferencias, pero ya no veo "Eliminar" como opción en el menú desplegable. Esto solo me afecta en la Wikipedia en inglés. En cy sigo teniendo los mismos derechos que ayer y puedo ver las mismas opciones, pero estoy usando la misma máscara en ambas, así que no entiendo por qué ha sucedido esto. ¿Alguna idea? Deb ( discusión ) 15:21 1 oct 2024 (UTC) [ responder ]
Probablemente solo te falte el enlace. Si te aparece un formulario de eliminación en https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/User:Deb/sandbox?action=delete, aún puedes eliminar. Hay diferentes menús desplegables según las preferencias. ¿Cuál es tu skin, cómo se llama tu menú desplegable y tienes una opción de eliminación en "Herramientas" en https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/User:Deb/sandbox?safemode=1&useskin=vector-2022? PrimeHunter ( discusión ) 16:58 1 oct 2024 (UTC) [ responder ]
Gracias, tienes razón. Eso parece aún más extraño. No veo ninguna diferencia en mis preferencias entre en y cy. Uso la skin predeterminada de 2022. Deb ( discusión ) 17:05 1 oct 2024 (UTC) [ responder ]
Hice tres preguntas. PrimeHunter ( discusión ) 18:45 1 oct 2024 (UTC) [ responder ]
Gracias. Lo que hayas hecho parece haber funcionado. Deb ( discusión ) 19:14 1 oct 2024 (UTC) [ responder ]
Problema que tengo con la plantilla de calendario.
Hola, hace poco hice que {{ Calendar }} sea compatible con el modo oscuro. Sin embargo, cuando llamo al calendario directamente, obtengo un texto oscuro que no funciona con el modo oscuro. Pero cuando llamo "Calendar/table", sí funciona. No puedo entender por qué. ¿Alguien tiene alguna idea de por qué?
Corregido en Special:Diff/1248831925 . Los elementos HTML con "background" en el código CSS obtienen un color de texto anulado. Por lo tanto, las propiedades "background" deben eliminarse (como en {{ Calendar }} ) o color: var(--color-base, #202122)agregarse ( ejemplo ). — andrybak ( discusión ) 18:20 1 oct 2024 (UTC) [ responder ]
He notado que es posible usar enlaces a las entradas individuales en WP:RSP , por ejemplo WP:RSP#Alexa Internet , aunque no haya un ancla incrustada normal. Supongo que esto tiene que ver con la id="Alexa Internet"línea. Me gustaría agregar una funcionalidad similar a {{ NRHP row }} , de modo que sea posible vincular directamente a una entrada sin su propio artículo. ¿La forma de hacer esto sería agregar una id="{{{name|}}}"línea a la plantilla? ¿Hay algo más que deba tener en cuenta con respecto a esto? Sdkb talk 04:30, 2 de octubre de 2024 (UTC) [ responder ]
@ Sdkb : Ver Plantilla:Anclaje#Uso en tablas (párrafo que comienza Si es necesario que un ancla esté en alguna de estas posiciones ) para ver ejemplos del atributo en tablas. Tenga en cuenta que el valor de un atributo debe ser único dentro del documento. Esto significa que es potencialmente inválido, ya que si usa más de una vez (una situación muy probable), y dos o más de ellos no tienen parámetros, terminará con dos instancias diferentes de . Pruebe algo como para evitar identificadores vacíos. -- Red rose64 🌹 ( discusión ) 09:33, 2 de octubre de 2024 (UTC) [ responder ]id=id=id="{{{name|}}}"{{NRHP row}}|name=id=""{{#if:{{{name|}}}|id="{{{name|}}}"}}
Español:https://html.spec.whatwg.org/multipage/dom.html#global-attributes dice: "Cuando se especifica en elementos HTML, el valor del atributo id debe ser único entre todos los ID en el árbol del elemento y debe contener al menos un carácter. El valor no debe contener ningún espacio en blanco ASCII". El espacio en blanco ASCII incluye un espacio normal, pero yo ignoraría esta regla. Significa que algunas funciones no pueden hacer referencia al id, pero si solo está destinado a enlaces, entonces no debería ser un problema. Me sorprendería si algún navegador se negara a saltar a un id que infrinja la regla. El problema se puede evitar colocando id dentro del contenido de una celda que no cuente como un elemento HTML. Pero los enlaces funcionan mejor si id está en la declaración de fila como WP:RSP y muchas otras tablas donde infringimos la regla. Esto garantiza que el navegador salte a la parte superior de la fila. Si id está al comienzo del contenido de la celda con centrado vertical, entonces el navegador puede saltar al comienzo del contenido mostrado en esa celda y la parte superior de la fila puede no ser visible. PrimeHunter ( discusión ) 11:22 2 oct 2024 (UTC) [ responder ]
No estoy seguro de lo que quieres decir con que el contenido de una celda no cuenta como un elemento HTML. Las celdas de una tabla son elementos <td>HTML <th>. isaacl ( discusión ) 16:49 2 oct 2024 (UTC) [ responder ]
Estaba pensando en <td>something with id="foo bar"</td>, pero necesitas algo a lo que aplicar la identificación y, si <td><span id="foo bar"></span></td>lo haces, es solo otro elemento HTML, por lo que mi comentario probablemente fue incorrecto o irrelevante. PrimeHunter ( discusión ) 19:55, 2 de octubre de 2024 (UTC) [ responder ]
@ PrimeHunter : Si bien la especificación HTML lo dice, el software MediaWiki reemplaza los espacios en el id=valor con guiones bajos antes de que se publique la página (consulte también Discusión de plantilla:Anclaje#Guiones bajos con sustitución ). Hace algo similar con el fragmento de URL, por lo que funciona un enlace a https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Wikipedia:Village_pump_(technical)#Embedded%20anchors%20in%20tables. -- Red rose64 🌹 ( discusión ) 18:54, 2 de octubre de 2024 (UTC) [ responder ]
Gracias por la información. PrimeHunter ( discusión ) 19:55 2 oct 2024 (UTC) [ responder ]
Tenga en cuenta también que es posible que varias filas de NRHP (en la misma página) tengan el mismo nombre, lo que también daría lugar a identificadores duplicados. Estoy prácticamente seguro de que tal situación existe en algún lugar de las miles de páginas de listas de NRHP. (Es menos probable que el campo de nombre de una fila esté en realidad en blanco). Un candidato más probable para usar como identificador de ancla sería el refnum, que debería ser único en todas las filas de una página determinada. Magic ♪piano 18:31, 2 de octubre de 2024 (UTC) [ responder ]
Problema de sustitución
Desarrollé la subplantilla {{ Happy Adminship/year }} para leer páginas como Wikipedia:Birthday Committee/Calendar/October/2 y devolver el año en que alguien se convirtió en administrador si está en la lista. (Esto, a su vez, se puede usar en {{ Happy Adminship }} para proporcionar automáticamente el número de aniversario). Funciona (vista previa en User talk:JHunterJ ), excepto cuando se sustituye, que lamentablemente es la forma en que necesito que funcione ya que Happy Adminship está destinado a ser sustituido. ¿Alguien podría identificar qué problema está causando que la sustitución falle? Sdkb talk 09:04, 2 de octubre de 2024 (UTC) [ responder ]{{Happy Adminship/year}}
subst no realiza transclusiones en la página de destino a menos que tengan subst allí. Wikipedia:Comité de cumpleaños/Calendario/Octubre/2 contiene {{u|JHunterJ}} (2007). Cuando se usa en User talk:JHunterJ intentaste hacer coincidir con JHunterJ]] (2007)el cual estaría en el resultado después de la transclusión de {{ u }} . En cambio, hice coincidir directamente con JHunterJ}} (2007).[6] Si quieres que funcione tanto para la transclusión como para la sustitución, puedes hacer coincidir con ambos ]]y }}. Los comentarios están incluidos por subst, así que no incluí el comentario. PrimeHunter ( discusión ) 11:54, 2 de octubre de 2024 (UTC) [ responder ]
¡Gracias! Pasé demasiado tiempo intentando resolverlo y habría tardado mucho más sin tu ayuda. Sdkb talk 15:38, 2 de octubre de 2024 (UTC) [ responder ]
¿La generación automática de citas no funciona?
¿Soy solo yo o la generación automática de citas no ha funcionado con frecuencia durante los últimos días? Por ejemplo, acabo de intentar agregar una cita a https://x.com/fbirol/status/1727552771715395655 y obtuve el temido mensaje "No pudimos crear una cita para usted. Pruebe con otra fuente o cree una manualmente usando la pestaña "Manual" de arriba". Pero cuando agrego la misma fuente a Zotero y luego exporto una cita de Wikipedia desde Zotero, Zotero crea una cita de wikitexto bien formateada. Lo mismo está sucediendo con las citas del New York Times. Lo que hace que esto sea más extraño es que no puedo duplicar el problema si intento citar una fuente que ya se usa en la página. Clayoquot ( discusión | contribuciones ) 17:55, 2 de octubre de 2024 (UTC) [ responder ]
Este es un problema que continúa. Hasta donde sabemos, hay varias fuentes populares que terminan bloqueando nuestro servicio de generación de citas. Probablemente de forma automática, en función de la limitación de velocidad que se aplica cuando una cantidad suficiente de personas ha solicitado citas en un período de tiempo suficientemente breve.
Hay un ticket general para esto: T362379: Varios sitios web de noticias importantes (NYT, NPR, Reuters...) bloquean a citoid. DLynch (WMF) ( discusión ) 19:21 2 oct 2024 (UTC) [ responder ]
La lista de visitas más vistas de ayer (1 de octubre de 2024) tiene un elemento inusual que no había visto antes: con 96.959 visitas, la página número 24 más vista supuestamente es wiki.phtml , una página que aparentemente nunca existió. Fue la página número 124 más vista el día anterior. Me pregunto qué genera tráfico (el Archivo de Internet ha guardado la URL varias veces a lo largo de los años) y cómo se rastrean las visitas de una página inexistente. Hameltion ( discusión | contribuciones ) 22:04 2 oct 2024 (UTC) [ responder ]
No hay una respuesta sobre por qué está en la lista, pero en lugar de, por ejemplo, w/index.php?title=Pete_Rose, puedes hacer w/wiki.phtml?title=Pete_Rose. – 2804:F1...93:F040 (discusión) 22:27 2 oct 2024 (UTC) [ responder ]
Puede que no sea relevante, pero como administrador puedo ver dos revisiones eliminadas de julio de 2004. La primera solo decía [[Wikipedia:Dewey Decimal System/103|103]]. La segunda, un minuto después, añadió {{delete}}. Las entradas más antiguas en Special:Log/delete son de diciembre de 2004. PrimeHunter ( discusión ) 23:18 2 oct 2024 (UTC) [ responder ]
Es interesante lo de las eliminaciones que no se han registrado... El 2 de octubre se registraron otras 90.551 visitas ayer, pero las visitas masivas basadas en enlaces wiki (usando el enlace rojo aquí en https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Wikipedia:Village_pump_(technical)) solo registran 3 visitas en total. Sin embargo, no parece que se puedan reproducir visitas en absoluto para otros enlaces rojos de esta manera. Hameltion ( discusión | contribuciones ) 17:20 3 oct 2024 (UTC) [ responder ]
Suena como un robot al que hay que decirle que busque algo más a lo que atacar. Izno ( discusión ) 23:23 2 oct 2024 (UTC) [ responder ]
@ PrimeHunter : Gracias, pero lo siento, como la persona que restauró los viejos registros de eliminación en 2016 (ver más abajo), no me siento cómodo con que esa página esté vinculada de forma tan destacada (en realidad, nunca ha estado vinculada en ese mensaje del sistema hasta ahora). Mis dos razones principales son que (a) la cantidad de personas que necesitarán hacer uso de ella será mucho menor que la cantidad de personas que la malinterpretarán y/o intentarán estropear los enlaces relacionados (tengo experiencia personal con este tipo de cosas desde 2007 con una situación similar relacionada con el antiguo registro de bloqueos ) y (b) las razones de eliminación a menudo citaban el texto original de la página, lo que significa que contienen mucha información personal y maldad en general. El último punto es la razón por la que muchos de los registros de eliminación se eliminaron entre 2006 y 2016 ; es toda una historia cómo llegué a restaurarlos . Por lo tanto, revertiré parcialmente su edición a la página del espacio de nombres MediaWiki, citando este comentario. Graham87 ( discusión ) 06:17 3 oct 2024 (UTC) [ responder ]
Como compromiso, voy a agregar una nota sobre los registros de eliminación antiguos a un mensaje de interfaz que aparece al recuperar páginas eliminadas, MediaWiki:Undeletehistory , ya que solo verá una lista de ediciones eliminadas sin un registro de eliminación si es un administrador... y luego solo para páginas eliminadas a partir del 8 de junio de 2004. Graham87 ( discusión ) 06:53, 3 de octubre de 2024 (UTC) [ responder ]
@ Killarnee : ¿Lo habéis intentado cuando ya estabais conectados en otra wiki y cuando cerráis la sesión primero? PrimeHunter ( discusión ) 02:18, 3 de octubre de 2024 (UTC) [ responder ]
@Dreamy Jazz tal vez sea relevante para tu existencia dado lo que estás haciendo. Izno ( discusión ) 03:30 3 oct 2024 (UTC) [ responder ]
Era la cuenta de Wikitech y después de la fusión funciona. Muchas gracias. Killarnee ( discusión ) 12:05 3 oct 2024 (UTC) [ responder ]
¿Puede alguien que no sea mantenedor leer un archivo en toolforge?
ChristieBot (que mantiene GAN) se bloquea y no voy a estar frente a una computadora donde pueda acceder a toolforge hasta el domingo. Esto es particularmente frustrante porque hay una acumulación de trabajo pendiente de GAN en este momento y hasta que esto se solucione no se pueden realizar actualizaciones a la página de GAN. El problema probablemente se debe a una plantilla mal formada en una página de GAN (al menos esa ha sido la causa de errores inexplicables en el pasado), pero no tengo forma de ver el archivo de error en toolforge. No sé si los archivos de toolforge son visibles para las personas que no son mantenedores, pero si alguien aquí tiene acceso, eche un vistazo al archivo de registro christiebot-gan.err en tool ganfilter y envíeme un correo electrónico o publique aquí las últimas cincuenta líneas aproximadamente. Espero que haya un mensaje de error que indique en qué página estaba trabajando cuando ocurrió el bloqueo. Es probable que el fallo se deba a una excepción no detectada, ya que no soy un programador de Python con mucha experiencia, pero con suerte los mensajes de registro anteriores ayudarán a identificar la página para que se pueda limpiar, lo que debería permitir que el bot se ejecute. Gracias por cualquier ayuda. Mike Christie ( discusión - contribuciones - biblioteca ) 03:16, 3 de octubre de 2024 (UTC) [ responder ]
Por supuesto, Mike. Hawkeye7 (discutir) 03:29, 3 de octubre de 2024 (UTC) [ responder ]
Puedo ver el problema, pero lo dejaré en tus manos. Hawkeye7 (discutir) 03:33, 3 de octubre de 2024 (UTC) [ responder ]
Gracias, Hawkeye7. He solucionado el problema y realmente agradezco que hayas publicado esto tan rápido. Mike Christie ( discusión - contribuciones - biblioteca ) 07:23, 3 de octubre de 2024 (UTC) [ responder ]
Problema con el icono de la lista de seguimiento en el móvil
Seguimiento en la tarea T376359 de Phabricator
Seguimiento en la tarea T376414 de Phabricator
Hola, tengo un problema con la edición móvil. No puedo ver el ícono de la "Estrella" después de agregar un artículo a mi lista de seguimiento. El lugar donde solía estar ahora es solo un espacio en blanco. Cuando hago clic allí, funciona y elimina el artículo de la lista de seguimiento, y aparece la estrella. Sin embargo, cuando agrego el artículo a la lista de seguimiento nuevamente, la estrella desaparece. Este problema no ocurre en computadoras de escritorio. ¿Alguien más que edite a través del móvil puede confirmar esto? Grab Up - Talk 12:27, 3 de octubre de 2024 (UTC) [ responder ]
Estaba a punto de publicar una pregunta sobre esto. Me interesaría una respuesta sobre la estrella de la lista de vigilancia "invisible". Gracias por publicar esto en GrabUp : . Knitsey ( discusión ) 17:31, 3 de octubre de 2024 (UTC) [ responder ]
@ Knitsey : Además, mi icono de notificación se vuelve invisible cada vez que alguien como tú me etiqueta o me menciona. ¿Qué pasa, jajaja? Grab Up - Talk 17:34, 3 de octubre de 2024 (UTC) [ responder ]
Acabo de darme cuenta de eso. Me etiquetaron en una publicación y mi ícono estaba rojo, pero desapareció después de mirarlo, otro espacio en blanco. Knitsey ( discusión ) 17:37, 3 de octubre de 2024 (UTC) [ responder ]
Corrección: cuando tengo una notificación, aparece con un fondo blanco y una cantidad de notificaciones ligeramente blanquecinas. (La notificación roja ha desaparecido). Knitsey ( discusión ) 17:40 3 oct 2024 (UTC) [ responder ]
Sí, lo mismo. Grab Up - Talk 17:44, 3 de octubre de 2024 (UTC) [ responder ]
Parece que esto se rastrea en phab:T376359. Gracias. Quiddity (WMF) ( discusión ) 18:09 3 oct 2024 (UTC) [ responder ]
Nueva tarea creada (phab:T376414) para el error de color de fondo de las notificaciones. Quiddity (WMF) ( discusión ) 18:29 3 oct 2024 (UTC) [ responder ]
Más problemas de apariencia de enlaces en dispositivos móviles
Seguimiento en la tarea T376146 de Phabricator
Afortunadamente, los problemas con los enlaces que no deberían ser azules se han solucionado, pero ahora hay un nuevo problema. Todas las categorías, enlaces en los banners de las páginas de discusión y enlaces en los banners de mantenimiento ahora están subrayados en todo momento. Este no es el caso en la versión de escritorio. ¿Es esto intencional o es otro error visual? Gracias, QuicoleJR ( discusión ) 14:10, 3 de octubre de 2024 (UTC) [ responder ]
Acabo de ver esto, parece ser un nuevo desarrollo hoy. AusLondonder ( discusión ) 17:28 3 oct 2024 (UTC) [ responder ]
Parece que un aspecto de esto está cubierto por phab:T376146. Me pondré en contacto con los desarrolladores para ver si esa tarea cubre estos otros aspectos o si necesitan tareas independientes. Gracias por informar. Quiddity (WMF) ( discusión ) 17:37, 3 de octubre de 2024 (UTC) [ responder ]
Error de Interlang
Entonces, no voy a necesitar una foto para este error, ya que está en mi página de usuario. Cuando vayas a mi página de usuario, ¿ves un enlace interlingüístico en francés? Si es así, haz clic en él y te llevará a un artículo aleatorio sobre bombardeos en francés. El problema es que mi página de usuario no está en Wikidata, que es normalmente la forma en que se vinculan los idiomas. Estaba traduciendo ese artículo y, por alguna razón, cree que mi página de usuario es el artículo que traduje. Señor MemeGod 14:34 3 octubre 2024 (UTC) [ responder ]
@ Sir MemeGod Tenías uno de los enlaces interlingüísticos de estilo antiguo en tu página de usuario. Para incluir un enlace normal a una página en otro idioma, debes anteponerlo con dos puntos, es decir, [[:fr:Attentat du 25 juillet 1995 à la gare de Saint-Michel du RER B]]. Te lo arreglé. el wub "?!" 14:53, 3 de octubre de 2024 (UTC) [ responder ]
@ Sir MemeGod : No es un error, está descrito en WP:LOCALLINK y hay ocasiones en las que es deseable. Por ejemplo, vea la lista de idiomas para User:Redrose64 - esta es la lista de todos los Wikis que he editado en los últimos quince años. Si los hubiera agregado a Wikidata, la misma lista larga se mostraría en mis páginas de inicio en docenas de otros Wikis - pero no quiero eso, solo quiero que se muestre uno - el enlace a mi página de inicio aquí. Vea por ejemplo cy:Defnyddiwr:Redrose64 o fr:Utilisateur:Redrose64. De esta manera, evito que la gente en Wikipedia en francés busque en vano en Wikipedia en alemán y pruebe Wiki tras Wiki hasta que llegue a la correcta. -- Red rose64 🌹 ( discusión ) 18:26, 3 de octubre de 2024 (UTC) [ responder ]
Ah, vale. Me pareció un error, pero supongo que estaba equivocado. Señor MemeGod 18:28 3 octubre 2024 (UTC) [ responder ]
Error de base de datos, duración de escritura excedida
Acabo de recibir el siguiente mensaje de error que elimina tres See-alsos de un borrador, en esta edición :
Error de base de datosPara evitar generar un retraso de replicación alto, se canceló esta transacción porque la duración de escritura (5.3958411216736) superó el límite de 3 segundos. Si está modificando muchos elementos a la vez, intente realizar varias operaciones más pequeñas.[bf82d77e-9cdf-4b96-a5b2-5ac9cab8969a] 2024-10-03 15:00:40: Excepción fatal del tipo "Wikimedia\Rdbms\DBTransactionSizeError"
Parece que la edición se ha realizado sin problemas, a pesar del mensaje. ¿Podría suceder esto si, sin darme cuenta, presioné Publicar dos veces o algo así? No recuerdo haberlo hecho y realmente no sé qué sucedió. Todo está bien por mi parte, no necesito hacer nada, solo informar esto en caso de que sea una primera señal de que algo está sucediendo y que se debe vigilar. Mathglot ( discusión ) 15:11, 3 de octubre de 2024 (UTC) [ responder ]
¿Por qué los botones están distorsionados o con fallas?
Seguimiento en la tarea T376226 de Phabricator
Los botones de eliminar plantilla (mientras se edita un artículo), wikitexto (mientras se ve una revisión) y editar plantilla (mientras se edita un artículo) tienen fallas o están distorsionados. ¿Cómo puedo solucionar esto? Susbush ( discusión ) 15:12 3 oct 2024 (UTC) [ responder ]
Creo que se trata del mismo problema que T376226, que se está solucionando. Matma Rex talk 18:24, 3 de octubre de 2024 (UTC) [ responder ]
Sí, lo es Susbush ( discusión ) 18:56 3 oct 2024 (UTC) [ responder ]
Ayuda para escalar problemas de seguridad con Webauthn
Seguimiento en la tarea T358771 de Phabricator
Con la ayuda del personal de WMF, identificamos un problema crítico con webauthn que probablemente esté bloqueando a los usuarios de sus cuentas. El problema impide que webauthn activado en un dispositivo se use en otro dispositivo o entre sesiones de navegador. Esto significa que los usuarios pueden activar webauthn con la intención de proteger su cuenta y terminar perdiendo el acceso a Wikipedia. Debido a que relativamente pocos usuarios activan esta función a corto plazo, es posible que el problema no reciba la atención que merece. También disuadirá a los futuros usuarios de activar webauthn, que es una función de seguridad fundamental para proteger a la comunidad.
Ayúdenme a encontrar el contacto adecuado con el personal técnico de WMF para que me ayude a fusionar la solución. Es una solución de una sola línea del repositorio original, por lo que debería ser de bajo riesgo. Tonymetz 💬 16:50, 3 de octubre de 2024 (UTC) [ responder ]
Supongo que seríamos nosotros, el equipo de la Plataforma. Lo plantearé con el equipo y lo analizaremos. Matma Rex talk 19:30, 3 de octubre de 2024 (UTC) [ responder ]
Extensión para navegador de LLM "Add A Fact"
Después de leer [8] y la publicación y la discusión que siguió aquí, no creo que esta extensión del navegador esté lista para el ritmo de discusión de artículos en en.wiki. No estoy seguro exactamente de dónde expresar una inquietud sobre esto, así que por favor muevan este comentario si corresponde. @ Chemipanda , Ita140188 y Avatar317 : VQuakr ( discusión ) 20:04, 3 de octubre de 2024 (UTC) [ responder ]
@VQuakr Los comentarios probablemente deberían ir a meta:Talk:Future_Audiences/Experiment:Add_a_Fact . -- Ahecht ( PAGINA DE DISCUSION) 21:05, 3 de octubre de 2024 (UTC) [ responder ]
Eso estaría bien para darles retroalimentación; supongo que aquí estoy más buscando ver si hay un acuerdo sobre que esto no debería usarse en en.wiki todavía. VQuakr ( discusión ) 21:20 3 oct 2024 (UTC) [ responder ]
@ VQuakr Como referencia, aquí hay una lista de todas las ediciones realizadas con esta herramienta: https://hashtags.wmcloud.org/?query=addafact&project=en.wikipedia.org&startdate=&enddate=&search_type=or&user= 86.23.109.101 ( discusión ) 21:59, 3 de octubre de 2024 (UTC) [ responder ]
¡Es un enlace útil, gracias! Miré unos 10 enlaces al azar y todos parecían estar bien. Eran oraciones copiadas directamente de la fuente con el texto incluido en el parámetro de cita para la cita. ¿Quizás Chemipanda no lo usó correctamente (resaltó el título) o está ejecutando una versión de navegador desactualizada? Los editores deberían al menos mirar las publicaciones generadas para ver si son normales/válidas/coherentes y revertirlas si no lo son; esta herramienta aún es experimental.
Si esto funcionara como se promete, lo consideraría más útil que la gente simplemente publique nuevas fuentes en las páginas de discusión (lo que siempre es útil). --- Avatar317 (discusión) 22:39 3 oct 2024 (UTC) [ responder ]
Diferencias y enlaces específicos de comentarios
No estoy seguro si este es el lugar correcto o el Help Desk. De todos modos, tengo dos preguntas, por favor:
¿Hay alguna manera (por ejemplo, una herramienta) de extraer diferencias sin tener que revisar el historial de la página?
Cuando hago clic en la marca de tiempo de una firma, obtengo un enlace específico del comentario (por ejemplo, [9]). No pude encontrar ninguna página de ayuda sobre este tipo de enlace. ¿Existe algún motivo por el que proporcionamos diferencias en lugar de estos enlaces específicos de comentarios, que parecen mucho más fáciles de obtener?
Gracias, Gitz ( charla ) ( contribuciones ) 09:56, 4 de octubre de 2024 (UTC) [ respuesta ]
Podrías hacer todos los cálculos necesarios y crear un gráfico similar para BRI. Uwappa ( discusión ) 07:24 26 sep 2024 (UTC) 
A mí me funciona ¿Cuál es tu skin y navegador? -- Red rose64 🌹 ( discusión ) 20:26 28 sep 2024 (UTC) 
Resuelto