Wikipedia:Bomba de agua de pueblo (técnica)

No he usado la piscina comunitaria antes, así que lo siento si esto no está en el pueblo correcto. La Wikipedia móvil comienza hoy porque, por alguna razón, comenzó a dirigirme automáticamente a en.m.wikipedia.org en lugar de a la Wikipedia normal en.wikipedia.org. Incluso si elimino directamente el ".m" o "m.", simplemente me dirigirá automáticamente a ella nuevamente. Realmente lo odio y me resulta insoportable usarlo y me encanta mucho más la Wikipedia en inglés normal. No sé qué está causando este problema. No he visto a nadie discutiendo esto ni en el subreddit de Wikipedia (donde generalmente se discuten las actualizaciones) ni en Wikipedia:Noticias. Agradezco mucho cualquier ayuda con esto, ¡gracias! 92.236.211.53 ( discusión ) 13:55, 4 de octubre de 2024 (UTC) [ responder ]

Utilice el enlace "Escritorio" en la parte inferior de las páginas móviles para solicitar la versión de escritorio. PrimeHunter ( discusión ) 14:00, 4 de octubre de 2024 (UTC) [ responder ]

¡Gracias por tu rápida respuesta! Ya probé esto y, lamentablemente, el resultado es que se muestra la versión literal del sitio web para escritorio, lo que genera una gran cantidad de espacio negativo y una ubicación incómoda del texto junto a las imágenes debido a que el sitio web intenta funcionar en el móvil horizontal. El sitio funcionaba perfectamente en el móvil antes. ¿Esto también sucede en tu teléfono? 92.236.211.53 ( discusión ) 14:07, 4 de octubre de 2024 (UTC) [ responder ]

Estoy escribiendo desde el escritorio porque también me enteré hoy de que la IP de mi teléfono (esta misma IP) quedó atrapada en un bloqueo de rango para bloquear a un usuario específico (¿pero ahora está resuelto?). Pensé ahora que esto podría ser lo que está causando esto, pero acabo de crear una cuenta en el móvil y todavía se dirige automáticamente a en.m.wikipedia. No tengo idea de qué hacer 92.236.211.53 ( discusión ) 14:28, 4 de octubre de 2024 (UTC) [ responder ]

Nombre del dispositivo:Pixel 6a

Modelo:Pixel 6a

Versión de Android: 12

Ojalá esta información sirva para saber cómo revertir este problema. Lo envié desde mi móvil. 92.236.211.53 ( discusión ) 16:48 4 oct 2024 (UTC) [ responder ]

El comportamiento que estás experimentando es como siempre ha funcionado. La "solución alternativa" que proporcionó Primehunter funciona como siempre ha funcionado. No hay forma de "arreglarlo". Lo más parecido que puedes hacer es tener una cuenta, cambiar la preferencia de apariencia de la cuenta y luego usar el enlace "usar escritorio" cuando hayas iniciado sesión y termines en el sitio web móvil. Quizás esto sea suficiente para ti. Izno ( discusión ) 18:31, 4 de octubre de 2024 (UTC) [ responder ]

Volví a revisar las capturas de pantalla que tomé y vi que tú y Primehunter tenían razón, siempre fue "en.m.wikipedia". Creo que hubo una actualización del esquema de colores claros básico de Wikipedia para dispositivos móviles que provocó que el complemento que estaba usando, darkreader, lo representara de manera diferente.

Observo que el texto en las tablas es más grande y, en mi opinión, los colores no funcionan bien juntos ni en el modo oscuro oficial ni al usar mi complemento en el modo claro.

Wikipedia actual que no me gusta (modo claro + lector oscuro) de hoy: https://imgur.com/a/wnNflgF

Wikipedia correcta, solo modo oscuro sin complementos, también hoy: https://imgur.com/a/4xdBsow

Esquema de colores anterior de Wikipedia para dispositivos móviles (modo claro+lector oscuro), del 28 de abril: https://imgur.com/a/up24a8G

¿Hay alguna manera de volver a cómo era antes porque realmente prefiero cómo era literalmente ayer? Lamento sinceramente los malentendidos 92.236.211.53 ( discusión ) 19:33 4 oct 2024 (UTC) [ responder ]

¿Qué es lo que no te gusta específicamente de la versión "actual"? Izno ( discusión ) 00:09 5 oct 2024 (UTC) [ responder ]

Hay un mayor contraste entre las letras y el fondo oscuro, el violeta que muestra los enlaces en los que se hizo clic es un violeta más claro, por lo que hay que forzar la vista más para distinguirlo, el texto en las tablas es más grande de lo necesario, mientras que el texto en el resto de los artículos todavía tiene su tamaño anterior, muy bueno y legible (que se muestra en la comparación de imgur vinculada arriba), y no entiendo cómo sucedió eso.

No sé de qué otra manera describirlo, pero parece que hay un filtro blanco o azul sobre los artículos que me hace doler los ojos. Puedo hacer otra comparación con Imgur si eso ayuda a explicar a qué me refiero (aunque esta vez solo dos enlaces de imágenes). 92.236.211.53 ( discusión ) 15:35, 6 de octubre de 2024 (UTC) [ responder ]

Si creas una cuenta o agregas ?useskin=timeless, la versión de escritorio será un poco más compatible con dispositivos móviles. Gryllida ( discusión , correo electrónico ) 07:29 7 oct 2024 (UTC) [ responder ]

He creado una cuenta y no ha revertido la interfaz de usuario a como estaba antes, lo siento.

?useskin=timeless está funcionando muy bien, gracias. Es una molestia pegarlo en la URL de cada nuevo artículo en el que hago clic, ya que se restablece al horrible valor predeterminado en cada nuevo enlace o página que se carga o cuando se abre el editor. ¿Hay alguna manera de convertirlo en el valor predeterminado, ya que también será malo cuando esté leyendo con datos móviles, ya que tendré que cargar el sitio dos veces? ¡Muchas gracias de todos modos! 92.236.211.53 ( discusión ) 20:11, 9 de octubre de 2024 (UTC) [ responder ]

Sí. Puedes configurarlo como predeterminado creando una cuenta, iniciando sesión con ella , luego yendo a tus Preferencias y en "Apariencia" seleccionando el diseño Timeless y luego Guardar. Pero eso es lo que te dijo Izno hace cinco días. —  JohnFromPinckney ( discusión / ediciones ) 21:03 9 oct 2024 (UTC) [ responder ]

Perdón por la respuesta tardía. Inicié sesión en esta cuenta y seleccioné la opción de apariencia atemporal, pero a pesar de eso, ¡todavía no se procesa automáticamente! Además, me disculpo con Inzo, creo que no entendí lo que están diciendo. AssanEcho ( discusión ) 20:37 12 oct 2024 (UTC) [ responder ]

Perdón por la respuesta tan tardía, sobre la redireccionación automática a en.m.wikipedia.org en lugar del sitio habitual en.wikipedia.org : podría haber ocurrido debido a una actualización reciente de Chrome y otros navegadores de Chrome. Después de esta actualización, el navegador siempre intentará brindarte la vista móvil, la única forma de evitarlo es activar la opción "vista de escritorio por defecto" en la configuración del navegador. Vestrian24Bio ( DISCUSIÓN ) 12:03 18 oct 2024 (UTC) [ responder ]

Está perfectamente bien. El problema principal ahora es que estoy tratando de encontrar una manera de lograr que el diseño atemporal sea el predeterminado en el móvil, ya que aún se establece automáticamente en el estándar, texto grande en las tablas y contraste más brillante que no me gusta. Usé Firefox en mi dispositivo móvil como navegador predeterminado y principal. ¡Muchas gracias por la ayuda de todos modos! 92.236.211.53 ( discusión ) 17:46, 19 de octubre de 2024 (UTC) [ responder ]

Puedes hacer que Wikipedia siempre te muestre la vista de escritorio mediante User:Writ Keeper/Scripts/unmobilePlus.js . Algunas apariencias (por ejemplo, Monobook con el "modo responsivo" habilitado) son en realidad más adecuadas para usar en mi teléfono que la versión "móvil" oficial. — Kusma ( discusión ) 19:40 19 oct 2024 (UTC) [ responder ]

Este script no funciona en los navegadores móviles de Chromium con vista móvil (al menos ya no), lo acabo de probar. Vestrian24Bio ( DISCUSIÓN ) 09:57, 20 de octubre de 2024 (UTC) [ responder ]

Durante las últimas semanas, a veces se me ha cerrado la sesión inesperadamente, a pesar de marcar la opción "recordarme" cada vez. Recientemente, me ha sucedido dos veces en las últimas 24 horas. Siempre sucede cuando he estado inactivo durante un tiempo, pero solo en el orden de horas, no días. No tengo conocimiento de haber cambiado alguna de mis configuraciones recientemente. Thryduulf ( discusión ) 20:15, 8 de octubre de 2024 (UTC) [ responder ]

Yo también. Creo que hay un ticket de phab que cubre este problema. Déjame buscarlo rápidamente NightWolf1223 < Howl at me • My hunting > 20:55, 8 de octubre de 2024 (UTC) [ responder ]

He tenido el mismo problema durante una semana aproximadamente, simplemente asumí con cierta pereza que se solucionaría en algún momento. -- LCU A ctively D isinterested « @ » ° ∆t ° 21:08, 8 de octubre de 2024 (UTC) [ responder ]

Probablemente el mismo problema que T372702. Matma Rex talk 16:16 9 oct 2024 (UTC) [ responder ]

No sé si esta secuencia de acciones tiene un detonante.

1. cerrar sesión explícitamente en una máquina (esto invalida todas las cookies de inicio de sesión en todos los dispositivos)
2. Inicie sesión en en.wp en un dispositivo diferente y seleccione "Mantener la sesión iniciada (hasta un año)". Ahora tengo una nueva cookie de inicio de sesión.
3. Microsoft me informa que las actualizaciones requieren instalación, así que termino lo que estoy haciendo...
4. ... cierra Firefox, ve a "Inicio" → "Apagado" → "Actualizar y reiniciar", espera un tiempo. Haz café. Limpia un montón de correo basura. Abre Firefox...
5. ... y vuelvo a mi lista de seguimiento. Una edición agrega una imagen a un artículo, algo que me genera sospechas, así que:
6. Visito Commons. Me dice que no he iniciado sesión y que debo volver a cargar la página. En mi experiencia, esto nunca funciona, pero seguir un enlace de Commons diferente sí funciona; así que voy al historial de la página. Ahora aparece como que he iniciado sesión.
7. Todavía en Commons, sigo un enlace a en.wp - No he iniciado sesión
8. Regresar a Commons, visitar otra página, aún con la sesión iniciada
9. Ve a Meta: estoy conectado allí
10. Intente en.wp nuevamente - no inició sesión

¿Por qué en.wp podría dejar de reconocer mi cookie de inicio de sesión cuando Commons y Meta están perfectamente de acuerdo con ello? -- Red rose64 🌹 ( discusión ) 20:17, 9 de octubre de 2024 (UTC) [ responder ]

El hecho de no iniciar sesión automáticamente en algunas wikis parece una especie de protección anti-seguimiento en el navegador. Commons y Meta comparten el mismo dominio principal con login.wikimedia.org, donde se almacena la cookie de sesión central, por lo que las restricciones del navegador sobre el acceso a cookies entre wikis son más relajadas.

¿Ayuda hacer clic en el enlace de inicio de sesión en la parte superior de la página de enwiki? Eso debería funcionar en Firefox. Tgr (WMF) ( discusión ) 18:26 10 oct 2024 (UTC) [ responder ]

@ Tgr (WMF) : Creo que te perdiste algo: mi inicio de sesión correcto (que me pedía que ingresara mi nombre y contraseña) estaba en Wikipedia en inglés. Cuando fui a Commons e inicié sesión allí, se cerró mi sesión en Wikipedia, pero seguí con la sesión iniciada en Commons. -- Red rose64 🌹 ( discusión ) 20:16, 10 de octubre de 2024 (UTC) [ responder ]

Sí, la parte de la sesión desconectada es el error que Matma Rex enlazó. Solo digo que es de esperar que el inicio de sesión en Commons y Meta sea más "fijo" en algunos navegadores: tu sesión en enwiki desapareció de alguna manera, tu sesión central en login.wikimedia.org permaneció y luego otras wikis de wikimedia.org pueden recuperar la sesión desde allí, pero las wikis de otros dominios no pueden. Tgr (WMF) ( discusión ) 21:31 10 oct 2024 (UTC) [ responder ]

Vale, no es aleatorio, pero es replicable:

1. En en.wp, inicie sesión (inicio de sesión completo usando Special:UserLogin, con nombre de usuario/contraseña)
2. Haga clic en este enlace: commons: - observe que ha iniciado sesión
3. Utilice el botón "atrás" del navegador para volver a en.wp
4. Presiona para recargar la página - observa que noF5 estás conectado
5. Haga clic en este enlace: commons: - observe que todavía está conectado a Commons

Esto también provoca la pérdida de datos de la sesión y más de una edición perdida. -- Red rose64 🌹 ( discusión ) 21:54 10 oct 2024 (UTC) [ responder ]

@ Redrose64 No puedo reproducir este comportamiento. RoySmith (discusión) 00:49 12 oct 2024 (UTC) [ responder ]

@ Redrose64 si puedes reproducirlo, ¿te importaría hacerlo con la extensión WikimediaDebug habilitada y la opción "Registro detallado" marcada? Tgr (WMF) ( discusión ) 15:59 13 oct 2024 (UTC) [ responder ]

Gracias Tgr, pero ahora está funcionando como se esperaba. No estoy seguro de cuándo comenzó a comportarse nuevamente, ¿ayer, tal vez ? -- Red rose64 🌹 ( discusión ) 09:39, 18 de octubre de 2024 (UTC) [ responder ]

No estoy seguro de cómo se puede relacionar esto, pero he notado recientemente (¿hace unas semanas?) que a veces, cuando vuelvo a mi lista de seguimiento después de ver o editar una página vinculada, obtengo una versión anterior de la lista de seguimiento. Supuse que tiene algo que ver con el almacenamiento en caché, ya que al borrar el caché aparece la versión más reciente de la lista de seguimiento. Donald Albury 19:50, 12 de octubre de 2024 (UTC) [ responder ]

Parece haber un problema con {{ cite web }} y las plantillas relacionadas en algunas páginas; consulte, por ejemplo, Beroidae , donde todas las referencias muestran "Error de Lua en Módulo:Citation/CS1/Configuration en la línea 2083: intento de indexar un valor booleano." en lugar de la referencia. Las referencias se muestran correctamente en el modo de vista previa, sin que se muestren errores de plantilla en el editor. Estoy usando Firefox con la máscara Monobook. Tevildo ( discusión ) 22:25 10 oct 2024 (UTC) [ responder ]

Le puse WP:NULLEDIT a la página y el error desapareció. No tengo idea de la causa. *Pppery* _{ha comenzado...} 22:35, 10 de octubre de 2024 (UTC) [ responder ]

Esto suele ocurrir cuando los componentes del módulo Citation Style 1 utilizados por las plantillas de citas se actualizan y quedan desincronizados durante unos momentos. Algunas páginas se vuelven a renderizar y almacenar en caché durante ese breve período de tiempo, y pueden generar errores cuando el código nuevo intenta llamar a un código anterior y falla de alguna manera. Con tantos millones de páginas, es inevitable que al menos algunas páginas se vean afectadas. La edición nula de los artículos afectados los vuelve a renderizar con todos los componentes del módulo actualizados. – Jonesey95 ( discusión ) 00:45, 11 de octubre de 2024 (UTC) [ responder ]

Gracias por las respuestas, lo intentaré si me vuelvo a encontrar con este problema. Tevildo ( discusión ) 15:50 11 oct 2024 (UTC) [ responder ]

Eche un vistazo al informe de problemas de @DannySI en T377379, parece que tiene algo que ver con Módulo:Cita/CS1 . Matma Rex talk 18:20, 16 de octubre de 2024 (UTC) [ responder ]

Igual que el anterior. Una edición nula debería solucionar el problema. – Jonesey95 ( discusión ) 18:34, 16 de octubre de 2024 (UTC) [ responder ]

El código que emite ese mensaje de error se agregó por primera vez en la actualización del conjunto de módulos del 23 de marzo de 2024. Hubo otra actualización el 17 de agosto de 2024. No recuerdo haber visto este mensaje de error antes de la actualización del 17 de agosto. Es posible que el editor Jonesey95 tenga razón. Aun así, me lo pregunto porque ese fragmento de código en particular no depende de ningún otro módulo de cs1|2. Debería funcionar siempre que haya una conexión MediaWiki entre commons y en.wiki.

El código utiliza datos tabulares almacenados en commons (c:Data:CS1/Identifier limits.tab). Se supone que los datos de esa tabla deben ser devueltos por mw.ext.data.get()en una secuencia de secuencias de Lua. El mensaje de error sugiere que la llamada a mw.ext.data.get()está devolviendo un valor booleano; podría ser true, podría ser false. No lo sé; un retorno booleano no se describe en ninguna de la documentación (muy limitada) que puedo encontrar sobre la función. ¿Alguien aquí lo sabe? Si un booleano es un retorno adecuado, ¿qué significa?

Si esto persiste, me temo que tendré que revertir el código que obtiene los datos de Commons. Es decepcionante. Prefiero actualizar esa pequeña tabla de datos cuando sea necesario en lugar de editar tanto el entorno de pruebas como los módulos CS1|2 en vivo...

—El monje trapense ( discusión ) 19:10 16 oct 2024 (UTC) [ responder ]

@Trappist el monje Esta función parece estar implementada aquí:

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/JsonConfig/+/refs/heads/master/includes/JCLuaLibrary.php

Línea 18 en adelante. Parece que puede regresar falsesi no logra cargar el contenido de la tabla. 86.23.109.101 ( discusión ) 20:47 16 oct 2024 (UTC) [ responder ]

Gracias por eso. Sospecho que tienes razón. Lamentablemente, no hablo .php, pero parece que en la línea 45 se intenta obtener el contenido de la página sin procesar de la memoria caché local. En caso contrario, se intenta consultar la base de datos. Si eso también falla, creo que $resultse establece en , falseque es el valor de retorno del que se queja Scributo. Pero, claramente, en este caso, la página (y, por lo tanto, su contenido) existe, por lo que nuncaJCLuaLibrary::get() debería devolver , ¿verdad?false

—El monje trapense ( discusión ) 23:28 16 oct 2024 (UTC) [ responder ]

@Trappist el monje Las distintas JCSingletonfunciones se encuentran en este archivo si quieres investigar un poco más.

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/JsonConfig/+/refs/heads/master/includes/JCSingleton.php

Tampoco puedo escribir php, pero getcontentparece intentar obtener el material del caché local nuevamente, luego, si eso falla, analiza el título y luego intenta recuperar el contenido de la base de datos, configurando el contenido en falsesi falla el análisis del título.

Veo un comentario en la parsetitlefunción sobre que las cosas están nullen "casos extraños" seguido de variables establecidas en false, por lo que podría haber algunos casos extremos en los que los datos de la tabla no se muestren a pesar de que la tabla existe. De cualquier manera, parece que hay algún comportamiento no documentado en que falsees una salida válida de mw.ext.data.get(), aparentemente en caso de un error.

En cuanto a solucionar este problema, creo que el módulo de citas debería verificar si el resultado mw.ext.data.get()es falsey, de ser así, ¿simplemente omitir las comprobaciones de límites? 86.23.109.101 ( discusión ) 00:04, 17 de octubre de 2024 (UTC) [ responder ]

Phab:T229742, reportado en la wikipedia rusa, ¿podría estar relacionado? 86.23.109.101 ( discusión ) 00:47 17 oct 2024 (UTC) [ responder ]

¿No se trata simplemente de un problema de conexión del lado del servidor? La Wikipedia en inglés y en ruso no están en el mismo clúster de servidores que Wikimedia Commons. Snævar ( discusión ) 15:41 17 oct 2024 (UTC) [ responder ]

¿ Es solo un problema de conexión del lado del servidor ? (énfasis añadido) Creo que no es algo trivial. Si el problema es un problema de conexión, ¿no estaríamos viendo algún tipo de falla al intentar obtener imágenes de Commons?

En este caso, JCLuaLibrary::get()aparentemente sabe que existe la página de datos tabulares: pruebe esto en la consola de depuración:

=mw.ext.data.get ("CS1/Identifier limits.tab")→ tabla

=mw.ext.data.get ("CS1/Identifier limits.ta")→ Error de Lua: argumento incorrecto n.° 1 para "obtener" (título no válido).

No he visto ninguno de esos mensajes de error y, hasta donde sé, no se ha informado de ninguno. Esto me sugiere que hay algo más que un problema de conexión que está provocando =mw.ext.data.get()que se devuelva falso.

—El monje trapense ( discusión ) 16:33 17 oct 2024 (UTC) [ responder ]

Me refiero a un problema de conexión temporal, ya que el caché del artículo ha expirado, las páginas se obtienen nuevamente y se produce un problema de conexión temporal, que luego se soluciona minutos después, pero para entonces ya es demasiado tarde. Esa es también la razón por la que funciona una edición de purga/nulo, porque ya han pasado minutos u horas y la conexión está bien en ese momento. Verificar la conexión ahora no me diría nada. Creo que solo un desarrollador de WMF puede estar absolutamente seguro, los usuarios no tienen las herramientas para verificar esto.

No creo que las miniaturas sean una buena comparación. Las miniaturas se almacenan en Swift y en centros de datos de almacenamiento en caché (consulte wikitech:Almacenamiento de medios). El centro de datos de almacenamiento en caché tiene los archivos más populares por uso en cada región. En cuanto a dónde están los centros de datos de almacenamiento en caché, hay dos en Europa, uno en Asia, uno en Sudamérica y uno en los EE. UU. (suponiendo que los servidores principales no tengan uno). Swift tiene sus propios servidores e incluso los archivos de Wikipedia en inglés también están allí. No creo que Swift esté dentro del clúster de Wikimedia Commons, que es s4 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s4.dblist). La Wikipedia en inglés está en s1 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s1.dblist), por sí sola, debido a su gran tamaño. La Wikipedia en ruso está en s6 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s6.dblist). No sé cómo se almacena el espacio de nombres de datos en Wikimedia Commons, pero supongo que estaría en s4. Snævar ( discusión ) 05:20 18 oct 2024 (UTC) [ responder ]

Si busco "Módulo:Cita/CS1/Configuración en la línea 2083", se devuelven 70 resultados. Si purgo la primera entrada y actualizo la búsqueda, hay 57 resultados. Si purgo la primera entrada y actualizo la búsqueda, vuelve a 70 resultados, y al purgar y actualizar, vuelve a aparecer 57. Puedo seguir repitiendo esto, los mismos artículos aparecen en la parte superior de los resultados de búsqueda (diferentes artículos para cada conjunto de resultados de búsqueda). Sin realizar una purga o una edición ficticia, los resultados siguen siendo los mismos.
Las entradas tampoco se actualizan, muy pocas de las entradas tenían realmente el mensaje de error y se corrigieron al purgarlas. Esto no cambia el resultado. Pensé que esto era solo que la búsqueda se estaba actualizando lentamente, pero este problema se ha informado un par de veces anteriormente en Help talk:Citation Style 1 . Así que he estado buscando y purgando todo lo que encuentro. Algunas de las entradas en la búsqueda no han tenido este error en semanas. No sé si esto se relaciona con el error 2083 o con un problema separado con la búsqueda, pero es repetible y extraño. -- LCU A ctively D isinterested « @ » ° ∆t ° 21:09, 17 de octubre de 2024 (UTC) [ responder ]

Hice un borrador de caja de usuario

Este usuario intenta reducir el sesgo de género en Wikipedia .

,

pero quiero poner un salto de línea entre "reducir" y "Género". ¿Alguien sabe cómo hacer esto? Walter Tau ( discusión ) 17:31 13 oct 2024 (UTC) [ responder ]

{{salto de línea}}? MM (Dame información.) ^(Victorias) 17:33, 13 de octubre de 2024 (UTC) [ responder ]

¡Gracias! ¡Funcionó! Walter Tau ( discusión ) 17:37 13 oct 2024 (UTC) [ responder ]

Muy bien. Disfruto de tu ruptura de muchas líneas. MM (Dame información.) ^(Victorias) 17:38, 13 de octubre de 2024 (UTC) [ responder ]

aún más simple, simplemente pon <br />. — xaosflux ^Talk 19:21, 13 de octubre de 2024 (UTC) [ responder ]

Existe una ventaja en evitar el uso de HTML. Creo que es probablemente la forma canónica de hacerlo. También admite saltos de línea múltiples. Saludos cordiales: Rich Farmbrough 15:18, 17 de octubre de 2024 (UTC).{{Break}} [ responder ]

¿Qué tal un espacio indivisible? Johnuniq ( discusión ) 22:10 17 oct 2024 (UTC) [ responder ]

Las fuentes HT ya no se pueden agregar automáticamente a través de gadgets de referencia como ProveIt y VisualEditor , solo de forma manual. ¿No se puede solucionar esto, como se hizo con otros sitios web como The Times of India ? Kailash29792 (discusión) 05:20 15 oct 2024 (UTC) [ responder ]

Hace unos meses que tengo el mismo problema con las fuentes HT, aunque todas las demás parecen funcionar bien. Vestrian24Bio ( DISCURSO ) 12:12 18 oct 2024 (UTC) [ responder ]

¿Cómo puedo agregar botones a la herramienta de respuesta (parte de DiscussionTools)? Polygnotus ( discusión ) 17:38 15 oct 2024 (UTC) [ responder ]

@ Polygnotus La herramienta de respuesta no está diseñada para que el usuario final la pueda personalizar fácilmente. Si desea solicitar una nueva función para todos, puede hacerlo en mw:Extension talk:DiscussionTools. Si está intentando escribir su propio WP:USERSCRIPT para modificar la herramienta de respuesta, deberá hacer algo como . -- Ahecht ($('.oo-ui-toolbar-tools:not(.oo-ui-toolbar-after)').append(CODE_FOR_YOUR_NEW_BUTTON)
PAGINA DE DISCUSION) 17:42 16 octubre 2024 (UTC) [ responder ]

@ Ahecht : Gracias. Hubiera escrito mi propio script de usuario, pero utilizan un área de texto ficticia un tanto extraña, mientras que lo real es en realidad un montón de divs. Es terriblemente confuso para un dinosaurio tecnológico como yo. Tendría que sumergirme en el código para encontrar una forma de agregar mis propios botones. He publicado una solicitud en mediawiki.org. Polygnotus ( discusión ) 17:58, 16 de octubre de 2024 (UTC) [ responder ]

Bastante complicado.

si ( mw . config . get ( 'wgDiscussionToolsFeaturesEnabled' )) { mw . loader . usando ( 'ext.discussionTools.ReplyWidget' , () => { ve . ui . HelloWorldCommand = function VeUiHelloWorldCommand () { ve . ui . HelloWorldCommand . super . call ( this , 'helloWorld' ); }; OO . heritageClass ( ve . ui . HelloWorldCommand , ve . ui . Command ); ve . ui . HelloWorldCommand . prototipo . ejecutar = () => { alerta ( '¡Hola mundo!' ); devuelve verdadero ; }; ve . ui . commandRegistry . register ( new ve . ui . HelloWorldCommand ()); ve . ui . HelloWorldTool = function VeUiHelloWorldTool () { ve . ui . HelloWorldTool . super . apply ( this , argumentos ); }; OO . heritageClass ( ve .ui.HelloWorldTool , ve.ui.Tool ) ; ve.ui.HelloWorldTool.static.name = ' holaMundo ' ; ve.ui.HelloWorldTool.static.icon = ' ayuda ' ; ve.ui.HelloWorldTool.static.title = ' Hola mundo ' ;​​​​​​​​​​​​​​​​​​​​​​​                             ve . ui . HelloWorldTool . static . commandName = 'holaMundo' ; ve . ui . toolFactory . register ( ve . ui . HelloWorldTool ); mw . loader . moduleRegistry [ 'ext. discussionTools. ReplyWidget' ]. packageExports [ 'dt-ve/CommentTarget.js' ]. static . toolbarGroups [ 3 ]. include . push ( 'holaMundo' ); }); }  

Basado en mw:VisualEditor/Gadgets. Nardog ( discusión ) 13:58 18 oct 2024 (UTC) [ responder ]

Esta búsqueda dice que muestra "Resultados 1 – 6 de 6", pero en realidad solo muestra 5 resultados:

Usuario:RoySmith/sandbox/test/foo/f2f2...2 bytes (1 palabra) - 17:11, 17 de octubre de 2024Usuario:RoySmith/sandbox/test/foo/f3f3...2 bytes (1 palabra) - 17:12, 17 de octubre de 2024Usuario:RoySmith/sandbox/xxxcomida...3 bytes (1 palabra) - 22:10, 8 de mayo de 2024Usuario:RoySmith/sandbox/test/bar/b1b1...2 bytes (1 palabra) - 17:11, 17 de octubre de 2024Usuario:RoySmith/sandbox/test/foo/f1f1...2 bytes (1 palabra) - 17:12, 17 de octubre de 2024

RoySmith (discusión) 17:34 17 oct 2024 (UTC) [ responder ]

¡¿Qué demonios?! Acabo de volver a ejecutar la búsqueda y ahora dice "Resultados 1 – 5 de 5". ¿Está ocurriendo algún extraño almacenamiento en caché? RoySmith (discusión) 17:37 17 oct 2024 (UTC) [ responder ]

Puede confundirse con las redirecciones, en realidad hay 7 subpáginas en total, y algunas son redirecciones. Special:PrefixIndex/User:RoySmith/sandbox/ es más confiable para este tipo de consulta. — xaosflux ^Talk 18:19, 17 de octubre de 2024 (UTC) [ responder ]

No dudes en abrir un informe de errores sobre el problema de los resultados de búsqueda con un desfase de un dígito, tu captura de pantalla puede ayudar. — xaosflux ^Talk 18:27, 17 de octubre de 2024 (UTC) [ responder ]

T377501 RoySmith (discusión) 18:59 17 oct 2024 (UTC) [ responder ]

Esto no es poco común. La búsqueda funciona fragmentándose en varios nodos (y un resultado puede estar en varios de esos nodos) y luego extrayendo los resultados de esos múltiples nodos. También funciona con un retraso prolongado en términos de actualización. Estas características lo hacen rápido (más rápido que hacer la misma búsqueda en la base de datos principal) y es por eso que la búsqueda usa una base de datos separada, pero también pueden causar inconsistencias menores como estas para fragmentos de tiempo. — Th e DJ ( discusión • contribs ) 09:15, 18 de octubre de 2024 (UTC) [ responder ]

Quiero que todos los artículos que tengan el si:සැකිල්ල:El cuadro de navegación de Monarchs of the Sinhala Kingdom caigan en una categoría específica. ¿Cómo hacer eso? la categoría es ප්‍රවර්ගය:සිංහලේ රජවරු (reyes cingaleses). Si es posible, ¿alguien puede editar el código?

Entonces, cuando esté listo, será como: cada página que tenga esta plantilla que incluya este cuadro de navegación se agregará automáticamente a esa categoría. Sería bueno si la opción de ingreso de categorías fuera como en "asbox" para que podamos ingresar la categoría respectiva en los cuadros de navegación respectivos en las plantillas. ¿O hay una manera fácil de hacer esto sin editar los módulos? VihirLak007 ^{¡envíame un mensaje!} / _duh. 22:00, 17 de octubre de 2024 (UTC) [ responder ]

Respondido en Wikipedia: Help desk#navbox help . PrimeHunter ( discusión ) 22:37 17 oct 2024 (UTC) [ responder ]

Dentro de la Wikipedia en inglés podemos usar varios otros tipos de fuentes para editar las páginas de los usuarios. En si:wikipedia.org (proyecto de Wikipedia en cingalés) solo tenemos una fuente predeterminada. ¿Hay alguien que pueda hacer que podamos usar otras pocas fuentes cingalesas famosas con licencia gratuita dentro de la Wikipedia en cingalés?

Le pregunté al único administrador más activo en ese proyecto aquí, él dice que no tiene el conocimiento técnico para esto, por eso estoy buscando ayuda aquí.

A continuación se muestran algunas fuentes cingalesas con licencia gratuita:

• fuente.akasa
• fuente cingalés

VihirLak007 ^hmu! / _claro. 13:19, 18 de octubre de 2024 (UTC) [ respuesta ]

La forma correcta es pedirle a phabricator que agregue esas fuentes al "Selector de idioma universal". Además, intente usar el ícono de engranaje junto al encabezado "idiomas" en la barra lateral izquierda en el antiguo vector. Si está en el nuevo vector, entonces está debajo de idiomas junto al título de la página y luego el ícono de engranaje. A veces, las personas piden fuentes que están presentes, pero es posible que no sean la fuente predeterminada. Snævar ( discusión ) 17:39, 18 de octubre de 2024 (UTC) [ responder ]

Esto es algo que me ha estado molestando por un tiempo. Sé que es posible hacer coincidir correos electrónicos con solo un poco de expresión regular, es decir (.*)?@(.*)?(\ |$), , pero ¿el escape con nospam realmente reduce el spam? Mi preocupación es realmente con el OCR porque, aunque se escapa el carácter literal @, solo se necesita un poco de OCR, que en este punto es mucho, mucho mejor que un humano, para obtener todos los correos electrónicos y continuar enviando el mismo spam.

Me pregunto si la mejor solución para esto sería tener otro CAPTCHA antes de que una persona pueda ver un correo electrónico o todos los correos electrónicos en la página. Esto se hace en YouTube y más. Esto se podría hacer para todos los enlaces mailto:, etc. Awesome Aasim 18:45, 18 de octubre de 2024 (UTC) [ responder ]

Mi preocupación es realmente con el OCR porque, aunque se escapa el carácter literal @, solo requiere un poco de OCR.

Sería tener otro CAPTCHA

¿Lo pensaste bien? Izno ( discusión ) 18:54 18 oct 2024 (UTC) [ responder ]

No creo que deba existir uno de esos CAPTCHA de texto. Hay otros mucho más inteligentes, como GeeTest y ReCaptcha, etc. La razón por la que no los utilizamos es que estamos muy, muy preocupados por la privacidad.

El CAPTCHA de texto fue derrotado hace más de una década gracias al OCR. La tendencia actual en CAPTCHAs que veo son aquellos en los que uno hace clic en controles deslizantes. Lamentablemente, tendremos que recopilar más datos para saber si alguien no es un humano.

Por ejemplo, el CAPTCHA de YouTube para ver una dirección de correo electrónico comercial en un canal es el CAPTCHA estándar "No soy un robot".

Si no queremos caer en el agujero negro del CAPTCHA, podemos limitar la velocidad. La limitación de velocidad detiene eficazmente el spam y podemos ir un paso más allá impidiendo que la gente vea las direcciones de correo electrónico cuando se utiliza un proxy abierto o Tor. Awesome Aasim 21:25, 18 de octubre de 2024 (UTC) [ responder ]

Probablemente funcione al menos algunas veces. Dudo que sea rentable incluso analizar HTML correctamente para recopilar direcciones de correo electrónico, y mucho menos renderizar toda la página y ejecutar OCR en ella. Aquí hay un artículo de alguien que probó algunas técnicas simples y descubrió que algunas de ellas realmente funcionan: https://spencermortensen.com/articles/email-obfuscation/ (aunque no probó lo que hace específicamente esta plantilla). Sería bastante fácil probarlo usted mismo, si no le importa esperar unos meses para obtener resultados: simplemente cree dos direcciones de correo electrónico únicas y publíquelas en algún lugar, una con la ofuscación de esta plantilla, otra sin ella; luego espere a que llegue el correo no deseado (o no). Matma Rex talk 19:10, 18 de octubre de 2024 (UTC) [ responder ]

Otra cosa que se podría intentar es reemplazar cada uno de los caracteres con sus valores Unicode/ASCII. Probablemente lo haría aún más confuso, aunque seguiría permitiendo direcciones de correo electrónico vinculadas y similares. Awesome Aasim 20:54, 18 de octubre de 2024 (UTC) [ responder ]

Un enlace de correo electrónico necesita que el correo electrónico literal esté presente en el enlace, de modo que pueda pasarse al cliente de correo electrónico. Puede ocultarse en el código fuente HTML al representarlo con Javascript, pero seguirá estando en la página resultante y, con la prevalencia generalizada de páginas web dinámicas en la actualidad, es común que los rastreadores web procesen las páginas recuperadas después de ejecutar cualquier código Javascript en ellas. isaacl ( discusión ) 22:24, 18 de octubre de 2024 (UTC) [ responder ]

En cuanto al OCR, existe una forma de ejecutar los navegadores en modo sin interfaz gráfica; en otras palabras, renderizar la página sin mostrar nada al usuario. Existen utilidades que también pueden tomar capturas de pantalla de las páginas con desplazamiento. Con el OCR tan omnipresente, dudo que no sea difícil configurar algo que lea páginas web de esa manera. Awesome Aasim 20:56, 18 de octubre de 2024 (UTC) [ responder ]

No estoy seguro de por qué te refieres a los navegadores sin interfaz gráfica. Es poco probable que alguien que recopile enlaces de correo electrónico esté usando un navegador en sí. (Lo que podría ayudar a disuadir a algunos recolectores es incluir algún texto oculto en cada página que esté diseñado para producir una gran cantidad de retrocesos en expresiones regulares de correo electrónico típicas, y tal vez causar un desbordamiento de memoria... excepto que también confundiría a los usuarios de buena fe). Implementar un sistema CAPTCHA efectivo que sea accesible y preserve la privacidad del usuario es un desafío que la WMF no ha resuelto durante muchos años (ver Wikipedia:Village pump (idea lab)/Archive 56 § Captchas para una discusión). isaacl ( discusión ) 21:56, 18 de octubre de 2024 (UTC) [ responder ]

En ese sentido, me gustó especialmente T354234. *Pppery* _{ha comenzado...} 23:01, 18 de octubre de 2024 (UTC) [ responder ]

¿Es algo que la WMF podría resolver por sí sola? Podemos tener un sistema CAPTCHA que sea FOSS y que pueda alojarse en Wikimedia y listo. O elegir una de las opciones propietarias que pueden o no ser las mejores (como GeeTest o reCAPTCHA o uCAPTCHA o etc.), aunque técnicamente recopilan más datos, y listo. Maxmind (que se utiliza para la información de IP) es propietario, al igual que todos los demás sitios WHOIS. ¿Acaso esos sitios y "whatsmybrowser" y otros no recopilan datos de navegación? Incluso Wikipedia tiene algún seguimiento utilizado por la WMF.

El problema fundamental con los datos y la privacidad es que un CAPTCHA tiene dos fuerzas opuestas: por un lado, es necesario recopilar la mayor cantidad de datos posible para evaluar si uno es humano o no. Por otro lado, no se desea almacenar esos datos indefinidamente. No existe una forma fácil y sencilla de equilibrar esto. Awesome Aasim 23:06, 18 de octubre de 2024 (UTC) [ responder ]

Si tiene en mente una buena implementación gratuita y de código abierto, vaya al ticket de Phabricator correspondiente mencionado en el otro hilo e infórmeselo a WMF. Sí, la tensión entre mantener la privacidad de los datos personales y usarlos como verificación de identidad es la razón por la que expandir el uso de CAPTCHA puede no ser el mejor enfoque. isaacl ( discusión ) 23:49, 18 de octubre de 2024 (UTC) [ responder ]

Recuerde, por supuesto, el principio de que el spam sólo funciona con los crédulos, y quienes usan técnicas para ocultar su dirección de correo electrónico a los spammers probablemente sean los menos crédulos, por lo que hay sorprendentemente pocos incentivos para eludir dichas técnicas. * Pppery * _{ha comenzado...} 23:01, 18 de octubre de 2024 (UTC) [ responder ]

¿Entre los "crédulos" se incluye "aquellos que ingenuamente piensan en reemplazar caracteres con imágenes para intentar disuadir el spam"?

Por cierto, creo que muchos spammers han pasado a otra cosa, como hacerse pasar por Amazon, Google, Microsoft o lo que sea, para realizar un ataque de phishing . Creo que obtienen estos correos electrónicos de filtraciones de datos reales, no solo de partes aleatorias de la web. En el caso de los números de teléfono, estos son consecutivos, por lo que no es demasiado difícil enviar spam por mensaje de texto. No obstante, todos podemos caer en ataques de phishing. Nadie sabe de dónde obtienen las direcciones de correo electrónico. Impresionante Aasim 23:11, 18 de octubre de 2024 (UTC) [ responder ]

Los spammers no suelen utilizar el reconocimiento óptico de caracteres (OCR) porque añade tiempo y costes de procesamiento. Consiguen muchas direcciones a las que enviar spam con un simple rastreo web. Los sistemas de captcha no son accesibles (para los ciegos, por ejemplo) o contribuyen a la formación de inteligencia artificial comercial (reCAPTCHA, otros) en la que una enciclopedia libre no debería estar involucrada. Y los spammers no tienen ningún problema en conseguir soluciones de captcha. Muchos sitios "gratuitos" que muestran un captcha en realidad están reenviando consultas a un spammer que utilizará la solución en su objetivo real. MrOllie ( discusión ) 23:17 18 oct 2024 (UTC) [ responder ]

Cuando veo imágenes con el visor de medios en cualquier artículo, a menudo navego a la siguiente imagen usando las flechas. Y cuando llego al final, ya no hay más flechas. Esto tiene sentido. Pero durante los últimos días, las imágenes se han estado reproduciendo en bucle, lo que resulta especialmente confuso cuando solo hay una imagen. ¿Cómo se puede solucionar esto? Gracias, Cremastra — discusión — c 19:55, 18 de octubre de 2024 (UTC) [ responder ]

Sí, hacer un bucle con una sola imagen sería confuso. Para solucionarlo, probablemente sea necesario enviar una tarea a Phabricator. Izno ( discusión ) 20:09 18 oct 2024 (UTC) [ responder ]

Proporcione un enlace a la página en la que ve este problema. — xaosflux ^Talk 20:28, 18 de octubre de 2024 (UTC) [ responder ]

Como dije, es cada página. Así que prueba con Thomas Cooke (actor) o Scolopendra alcyona . Cremastra — discusión — c 20:39, 18 de octubre de 2024 (UTC) [ responder ]

Se solicitó un bucle en phab:T77877 con código de Simon04 . Se implementó aquí ayer. No sé si consideró que generaría un "bucle propio" cuando solo hay una imagen como Scolopendra alcyona . PrimeHunter ( discusión ) 21:36 18 oct 2024 (UTC) [ responder ]

¿Hay alguna forma de desactivarlo por mi cuenta? Me resulta un poco molesto estar hojeando una galería de imágenes y pensar que hay más y luego terminar de nuevo en el principio. Es confuso y desorientador, como se señaló en el ticket de phab. Cremastra — discusión — c 21:44, 18 de octubre de 2024 (UTC) [ responder ]

No, no se puede desactivar por uno mismo (al menos no de forma trivial). He dejado un comentario en el ticket. Izno ( discusión ) 22:02 18 oct 2024 (UTC) [ responder ]

En algunos sitios web con bucles de fotos, se muestra "1 de 6", etc. en algún lugar de la pantalla (arriba a la derecha en IMDb), para que sepas qué tan avanzado estás y si has llegado al inicio. -- Red rose64 🌹 ( discusión ) 22:23, 18 de octubre de 2024 (UTC) [ responder ]

Jdlrobson ha respondido en el ticket que tienen la intención de agregar dicha numeración en la parte superior derecha y agregarán clases CSS para que los usuarios puedan deshabilitar el comportamiento. — Jts1882  | discusión 07:15 , 19 de octubre de 2024 (UTC) [ responder ]  

Vale, esto es algo que puede ser un problema que se deba investigar (probablemente no por mí) o puede que no sea importante.

Cuando miro el código fuente de, por ejemplo, Talk:Interpunct , usando Chrome, e intento validarlo en Free Formatter, encuentra caracteres no válidos como b7 (interpunct), a pesar de que HTML lo dice claramente <meta charset="UTF-8">. Por supuesto, podría ser culpa de Chrome o de que Windows no me permita cortar y pegar UTF8, pero ambas cosas parecen poco probables. ¿Estamos publicando UTF8 ilegal? Un saludo: Rich Farmbrough 23:16, 18 de octubre de 2024 (UTC).[ responder ]

No lo somos, la salida de ese validador es incorrecta. Matma Rex talk 00:30, 19 de octubre de 2024 (UTC) [ responder ]

Un ejemplo más pequeño:

<!DOCTYPE html><html><head><meta charset="UTF-8"><title>a</title><cuerpo><div>Este carácter '·' es válido</div></cuerpo></HTML>

Parece correcto... todavía hay errores en el formateador, incluso cuando se carga como archivo con codificación utf-8. Definitivamente es un problema de la herramienta. – 2804:F1...ED:5881 (discusión) 20:50 20 oct 2024 (UTC) [ responder ]

• H<span style="font-variant: small-caps; text-transform: lowercase;">ELLO</span>.se representa como HOLA .
• H<span class="smallcaps" style="font-variant-caps: all-small-caps;">ELLO</span>.se representa como HOLA .

En la segunda versión, que se utiliza en (que se representa como L ORD ), Safari 17.6 en MacOS crea espacios en blanco extraños después del final de la palabra. La primera versión está bien. ¿Existe una buena razón para no cambiar a la primera en plantillas como y ? — Kusma ( discusión ) 14:12, 19 de octubre de 2024 (UTC) [ responder ]{{LORD}}{{LORD}}{{Kangxi radical}}

En particular, ¿hay algún navegador en el que la primera versión falle? — Kusma ( discusión ) 05:52 20 oct 2024 (UTC) [ responder ]

Estoy viendo esto en la aplicación Firefox y obtengo los mismos resultados: el primero es bueno, el segundo tiene espacios en blanco adicionales. jlwoodwa ( discusión ) 19:05, 20 de octubre de 2024 (UTC) [ responder ]

No estoy seguro de lo que está pasando. Me di cuenta de esto recién ayer (18 de octubre). Hace tiempo que instalé User:Anomie/linkclassifier . El código que uso se actualiza para colocar el enlace en la barra lateral/caja de herramientas. Cuando hago clic en ese enlace en cualquier página, parece obligar a la página a recargarse y no resalta ninguno de los enlaces como solía hacerlo. Intenté usar las instrucciones actuales para cargar, pero no hubo diferencia. Uso la máscara Vector 2022 y también verifiqué en monobook; la recarga aún ocurre allí, aunque parece que al menos algunos de los enlaces se resaltan. Cualquier ayuda será apreciada. older ≠ wiser 15:29, 19 de octubre de 2024 (UTC) [ responder ]

@ Bkonrad : Bueno, ¿le has preguntado directamente a Anomie  ( discusión  · contribs )? Puede que su script sea antiguo, pero Anomie sigue existiendo (a partir de ayer), por lo que debería poder ofrecer consejos. -- Red rose64 🌹 ( discusión ) 15:54, 19 de octubre de 2024 (UTC) [ responder ]

Ayer hice algunos cambios, pero nada que debiera haber obligado a actualizar la página... Ah, cometí un error tipográfico. Lo siento. Debería estar corregido ahora (es posible que tengas que usar WP:Bypass your cache ). Anomie ⚔ 16:27, 19 de octubre de 2024 (UTC) [ responder ]

Gracias. Ahora todo parece estar bien. Pregunté aquí primero porque mi js tiene una mezcla de cosas que aprendí de otros aquí. older ≠ wiser 23:47, 19 de octubre de 2024 (UTC) [ responder ]

Según mw:Manual:User_table#user_touched, hay un user.user_touched, pero hasta donde sé, siempre es NULL. ¿Cuál es el estado actual de este campo? RoySmith (discusión) 22:37 19 oct 2024 (UTC) [ responder ]

El manual indica que es la última vez que el usuario inició sesión. Esos datos son privados. Los campos como este se eliminan de las réplicas de Toolforge, por lo que aparecen como nulos. – SD0001 ( discusión ) 22:57, 19 de octubre de 2024 (UTC) [ responder ]

Vale, eso tiene sentido. ¿Hay alguna lista de campos redactados en algún lugar? Sería genial si estuviera visible en el menú "Tablas de bases de datos" de Quarry :-) RoySmith (discusión) 23:01 19 oct 2024 (UTC) [ responder ]

@ RoySmith Aquí está el código que controla lo que se copia a las réplicas de toolforge:

https://gerrit.wikimedia.org/r/plugins/gitiles/operaciones/puppet/+/9e7303f945a7f665a50d6d745f40092a370c096c/modules/role/templates/labsdb/maintain-views.yaml

Entonces, para la tabla de usuarios:

usuario:
origen: usuario
vista: >
seleccionar id_usuario, nombre_usuario, nombre_real_usuario, NULL como contraseña_usuario, NULL como nueva_contraseña_usuario, NULL como correo_email_usuario,
NULL como opciones_usuario, NULL como usuario_tocado, NULL como token_usuario,
NULL como correo_email_usuario_autenticado, NULL como token_usuario_email, NULL como token_usuario_email_expires,
registro_usuario, NULL como tiempo_nueva_contraseña_usuario, conteo_de_edición_usuario, NULL como contraseña_usuario_expires

86.23.109.101 ( discusión ) 23:38 19 oct 2024 (UTC) [ responder ]

Redactamos user_touched pero no user_real_name??? RoySmith (discusión) 23:45 19 oct 2024 (UTC) [ responder ]

Si entiendo bien mw:Manual:$wgDefaultUserOptions, es un campo opcional que los usuarios pueden configurar (y que parece estar deshabilitado en la Wikipedia en inglés), para que se muestre en lugar de su nombre de usuario, por lo que, por diseño, está destinado a ser conocido abiertamente (y podría ser simplemente otro alias). isaacl ( discusión ) 01:26, 20 de octubre de 2024 (UTC) [ responder ]

No es posible configurarlo user_real_nameen los wikis de Wikimedia, por lo que no es necesario redactarlo. Está deshabilitado para no alentar a las personas a revelar más información de la necesaria. AntiCompositeNumber ( discusión ) 02:12 20 oct 2024 (UTC) [ responder ]

Solía ​​ser la última vez que el usuario inició sesión. Estoy bastante seguro de que eso ya no es así. Creo que ahora es la última vez que cambiaste tus preferencias. Bawolff ( discusión ) 15:29 22 oct 2024 (UTC) [ responder ]

Recientemente incorporé https://commons.wikimedia.org/wiki/Data:Navajo_Nation.map en Navajo Nation haciendo esto:

image_map = {{maplink-road|from=Nación Navajo.map}}

El mapa se ha incorporado correctamente, sin embargo, el color de "relleno" (por ejemplo, data.features.0.properties.fill) se ignora. Al menos en la versión incorporada. Cuando hago clic en el mapa en el artículo, el mapa expandido muestra el color de relleno. Entonces, ¿por qué el mapa incorporado no muestra el color de "relleno" y qué puedo hacer para solucionarlo? TerraFrost ( discusión ) 22:43 19 oct 2024 (UTC) [ responder ]

Lo siento si esto suena como una pregunta extraña o incluso estúpida, pero por favor lea hasta el final si no tiene sentido. Le prometo que sí.

• Wikipedia agregó recientemente el modo oscuro WP:DARK .
• Puedo acceder a Wikidata a través de, por ejemplo {{Infobox company| homepage = {{Official URL}}}}, . Esto es bueno y ahorra tiempo.
• No parece haber una manera de acceder a la propiedad ^[α] de la imagen del logotipo de Wikidata (P154) en una plantilla Infobox con un nombre similar.
  • Sé {{Infobox company}}que "regresaré" a P154 si se define
  • Otros cuadros de información {{infobox hospital}}no parecen poder hacer lo mismo.
  • Quizás sea un tonto que aún no lo ha descubierto, pero no creo haber visto ningún ejemplo en la naturaleza como el que he visto en{{Official URL}}
• Si lo hay y no he podido encontrarlo, ¿es el modo oscuro de Wikipedia lo suficientemente inteligente como para buscar la propiedad del esquema de color (P8798)?
  • Los únicos dos valores son el esquema de color oscuro sobre claro y el esquema de color claro sobre oscuro.
  • El P8798 está básicamente diseñado para esto ya

Podría ser útil poder hacer algo así {{logo image}}sin necesidad de que cada cuadro de información lo implemente directamente, y sería genial que se adaptara a las preferencias del modo oscuro de los usuarios. No estoy del todo seguro de si existe alguna forma de que MediaWiki "verifique" si un usuario está usando el modo oscuro y "responda" con algún tipo de variable que pueda usarse aquí.

Leer sobre Wikifunctions y Abstract Wikipedia me hizo pensar en cosas mucho más simples que quizás ya sean comunes en otros sitios en línea, pero que aquí aún no se han implementado. Verificar si el navegador de un usuario informa que "prefiere el modo oscuro" es cada vez más común.

Todavía uso Vector legacy (2010) con Dark Reader porque no me gustaron las barras laterales en el rediseño.

Solo para asegurarme de que no estaba siendo demasiado estúpido , ^[β] hice pruebas con Vector (2022) y parece que algunas páginas intentan tenerlo en cuenta. Por ejemplo, el logotipo de Apple Inc.[[File:Apple logo black.svg|frameless|upright=0.4|class=skin-invert]] es negro, por lo que se usa un editor en su cuadro de información (énfasis en class=skin-invert), pero eso realmente solo funciona con el modo oscuro de Vector (2022). Dark Reader no lo detecta, y me imagino que una about:flagsopción de Chromium para forzar el modo oscuro en todas partes tampoco lo hace.

-αβοοδ ( discusión ) 19:35 20 oct 2024 (UTC) [ responder ]

Tengo un problema al representar una tilde dentro de una etiqueta <math></math>:

¡Insatisfactorio!

Código fuente	Resultado
<math>x</math> ~ <math>y</math>	${\displaystyle x}$~${\displaystyle y}$
<math>x ~ y</math>	${\displaystyle x~y}$
<math>x \tilde y</math>	${\displaystyle x{\tilde {y}}}$
<math>x\tilde\y</math>	${\displaystyle x{\tilde {\ }}y}$

El resultado debería ser como en la primera línea, pero sin dividir el código en dos partes. ¿Es posible hacerlo? AstroOgier ( discusión ) 15:32 21 oct 2024 (UTC) [ responder ]

LaTeX utiliza \sim"líneas onduladas" que no son diacríticos. Así: . jlwoodwa ( discusión ) 15:41 21 oct 2024 (UTC) [ responder ]${\displaystyle x\sim y}$

Estoy escribiendo artículos sobre temas astronómicos en la Wikipedia en danés y me falta la posibilidad de insertar símbolos adecuados que representen grados (°), minutos de arco (′) y segundos de arco (″) dentro de <nowiki><math></math></nowiki> (afuera no hay problema como puedes ver).

¡Insatisfactorio!

Código fuente	Resultado
delta = - 67° 12′ 34.07″	${\displaystyle \delta }$= 67° 12′ 34.07″${\displaystyle -}$
delta = -67^circ 12' 34.07''	${\displaystyle \delta =-67^{\circ }12'34.07''}$
delta = -67° 12′ 34,07″	${\displaystyle \delta =-67}$° ′ ″${\displaystyle 12}$${\displaystyle 34.07}$

El del medio se acerca más al utilizar una sola etiqueta <math></math>, pero utiliza ^\circ como solución alternativa.

Sería adecuado tener las etiquetas \degree , \minute y \second para este propósito. ¿Se puede solucionar de alguna manera? ¿Dónde se debe aplicar? AstroOgier ( discusión ) 15:37 21 oct 2024 (UTC) [ responder ]

@ AstroOgier Esto se plantearía en mw:Extension talk:Math o en una solicitud de función en https://phabricator.wikimedia.org/maniphest/task/edit/form/102/?projects=Math -- Ahecht (
PAGINA DE DISCUSION) 17:34, 21 de octubre de 2024 (UTC) [ responder ]

Asian News International vs. Wikimedia Foundation ha sido borrado y protegido por la oficina . Su historial ya no es visible, pero no puedo encontrar ningún registro relacionado con la eliminación del historial. ¿Cómo es posible? Incluso un descuido genera una entrada de registro. jlwoodwa ( discusión ) 15:38, 21 de octubre de 2024 (UTC) [ responder ]

No importa, me he olvidado. Como se explica en Wikipedia:Oversight § Logging , la supervisión genera una entrada de registro, pero en Special:Log/suppress , que los editores normales no pueden ver. jlwoodwa ( discusión ) 16:00, 21 de octubre de 2024 (UTC) [ responder ]

(conflicto de edición) La omisión genera una entrada de registro que solo es visible para los supervisores, el resto no ve nada. Ver nota 9 para el ítem 5 de Wikipedia:Oversight#Operation sobre cómo eliminar una página con una opción 'Suprimir todas las ediciones' hace que el registro de eliminación se muestre en Special:Log/suppress (oversight log) en su lugar. Probablemente eso es lo que hicieron. 2804:F1...EE:EFBD (discusión) 16:00, 21 de octubre de 2024 (UTC) [ responder ]

Ú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.

Lo más destacado de la semana

• El equipo de Aplicaciones móviles ha publicado una actualización de la navegación de la aplicación iOS, que ya está disponible en la última versión de la App Store. El equipo ha añadido un nuevo menú de Perfil que permite un acceso sencillo a las funciones del editor, como Notificaciones y Lista de seguimiento, desde la vista de Artículo, y lleva el botón "Donar" a un lugar más accesible para los usuarios que están leyendo un artículo. Esta es la primera fase de una actualización de navegación planificada más amplia para ayudar a que la aplicación iOS pase de ser una aplicación centrada principalmente en el lector a una aplicación que admita totalmente la lectura y la edición. La Fundación Wikimedia ha añadido más funciones de edición y compatibilidad con la comunicación dentro de la wiki en función de las solicitudes de voluntarios de los últimos años.

Actualizaciones para editores

• Los lectores de Wikipedia ahora pueden descargar una extensión del navegador para experimentar con algunas ideas preliminares sobre posibles funciones que recomienden artículos para leer más, resuman artículos automáticamente y mejoren la funcionalidad de búsqueda. Para obtener más detalles y mantenerse actualizado, consulte la página de Experimentos de descubrimiento de contenido del equipo web y suscríbase a su boletín informativo.
• A finales de este mes, los editores que hayan cerrado sesión en estos 12 wikis comenzarán a tener cuentas temporales creadas. La lista puede cambiar ligeramente: se eliminarán algunos wikis, pero no se agregará ninguno. La cuenta temporal es un nuevo tipo de cuenta de usuario. Mejora la privacidad de los editores que hayan cerrado sesión y facilita la comunicación con ellos por parte de los miembros de la comunidad. Si mantiene alguna herramienta, bot o dispositivo en estos 12 wikis y su software utiliza datos sobre direcciones IP o está disponible para usuarios que hayan cerrado sesión, verifique si necesita actualizarse para que funcione con cuentas temporales. Hay disponible una guía sobre cómo actualizar el código. Lea más sobre el plan de implementación en todos los wikis.
• Ver las 33 tareas enviadas por la comunidad que se resolvieron la semana pasada. Por ejemplo, la semana pasada se crearon los idiomas ndebele meridional, ruteno panónico, obolo, iban y tai nüa de Wikipedia. [1][2][3][4][5]
• Ahora es posible crear funciones en Wikifunctions usando lexemas de Wikidata, a través del nuevo tipo de lexema de Wikidata lanzado la semana pasada. Cuando accedes a una de estas funciones, la interfaz de usuario proporciona un selector de lexema que te ayuda a elegir un lexema de Wikidata que coincida con la palabra que escribes. Después de pulsar Ejecutar, el lexema seleccionado se recupera de Wikidata, se transforma en un tipo de lexema de Wikidata y se pasa a la función seleccionada. Lee más sobre esto en el último boletín de Wikifunctions.

Actualizaciones para colaboradores técnicos

• Los usuarios de los sitios Wikimedia ahora pueden formatear fechas más fácilmente en diferentes idiomas con la nueva {{#timef:…}}función de análisis. Por ejemplo, {{#timef:now|date|en}}se mostrará como "22 de octubre de 2024". Anteriormente, {{#time:…}}se podía utilizar para dar formato a las fechas, pero esto requería conocer el orden de los componentes de fecha y hora y su puntuación intermedia. #timef(o #timeflpara la hora local) proporciona acceso a los formatos de fecha estándar que MediaWiki utiliza en su interfaz de usuario. Esto puede ayudar a simplificar algunas plantillas en wikis multilingües como Commons y Meta. [6][7]
• Los usuarios de Commons y Meta ahora pueden recuperar de manera eficiente el idioma del usuario usando {{USERLANGUAGE}}en lugar de usar {{int:lang}}. [8]
• El Consejo Asesor de Productos y Tecnología (PTAC) ya cuenta con sus miembros piloto, con representación en África, Asia, Europa, América del Norte y América del Sur. Trabajarán para abordar la iniciativa del Consejo de Tecnología de la Estrategia del Movimiento de contar con una plataforma tecnológica codefinida y más resiliente. [9]

A fondo

• Ya está disponible el último boletín trimestral de Growth. Incluye: un próximo módulo de actualizaciones de la comunidad en la página de inicio para recién llegados, nuevas opciones de configuración de la comunidad y detalles sobre nuevos proyectos.
• La Fundación Wikimedia es ahora socio oficial del programa CVE, que es un esfuerzo internacional para catalogar las vulnerabilidades de seguridad cibernética divulgadas públicamente. Esta asociación permitirá al Equipo de Seguridad publicar de forma instantánea registros de vulnerabilidades y exposiciones comunes (CVE) que afectan al núcleo, las extensiones y los aspectos de MediaWiki, junto con cualquier otro código del que sea responsable la Fundación.
• La lista de deseos de la comunidad ahora está probando traducciones automáticas para el contenido de la lista de deseos. Los voluntarios ahora pueden leer versiones traducidas automáticamente de los deseos y participar en las discusiones incluso antes de que lleguen los traductores para traducir el contenido.

Reuniones y eventos

• 24 de octubre - Seminario web de la serie de conferencias sobre educación wiki: Tecnología de código abierto: creación del panel de control de educación wiki, con la participación de pasantes de Wikimedia y un desarrollador web en el panel.
• 20–22 de diciembre de 2024: Indic Wikimedia Hackathon Bhubaneswar 2024 en Odisha, India. Un hackathon para miembros de la comunidad, incluidos desarrolladores, diseñadores y editores de contenido, para crear soluciones técnicas que mejoren las experiencias de los colaboradores.

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.

Entrega de mensajes de MediaWiki20:49 21 octubre 2024 (UTC) [ responder ]

Revisé las revisiones anteriores y también sucede allí. Tampoco puedo hacer clic en responder, el script se confunde. Esto no sucede con ninguna de las otras bombas de la aldea, ¿es algo de las actualizaciones anteriores (noticias técnicas)?
En caso de que no lo veas, para mí el div con id "villagepumpfaq", que se agrega manualmente en esta página, está consumiendo toda la página. – 2804:F1...96:C2CF ( discusión ) 23:21 21 oct 2024 (UTC) [ responder ]

Corregido. Izno ( discusión ) 23:31 21 oct 2024 (UTC) [ responder ]

Ah, fue vandalismo... por supuesto que lo fue (ni siquiera la primera vez). Busqué el árbol equivocado pensando que era un cambio de plantilla, debería haber leído Template:FAQ con más atención (o supongo que simplemente noté que hay un botón para "ver" y otro para "editar"). Gracias por arreglarlo. – 2804:F1...96:C2CF ( discusión ) 00:02 22 oct 2024 (UTC) [ responder ]

En la Lista Roja de la UICN de especies en peligro de extinción (Animalia) , la mayor parte del texto de la lista está en cursiva y se usa {{columns-list|style=font-style:italic;como si fueran nombres científicos, pero algunos textos no deberían estar en cursiva, por ejemplo, "(subpoblación del río Kootenai)". ¿Cómo puedo volver a cambiar eso a texto en letra latina sin estropear el patrón existente? Gracias.   SchreiberBike  |  ⌨  23:24, 21 de octubre de 2024 (UTC) [ responder ]

Usa {{ noitalic }} , así. – Jonesey95 ( discusión ) 23:31 21 oct 2024 (UTC) [ responder ]

Quizás otro día me hubiera dado cuenta, pero hoy te agradezco que me hayas señalado lo obvio. Gracias.  SchreiberBike  |  ⌨  23:53, 21 de octubre de 2024 (UTC) [ responder ]

No hay problema. Todos estamos aquí para ayudarnos unos a otros. – Jonesey95 ( discusión ) 04:10 22 oct 2024 (UTC) [ responder ]

Hola a todos, el 27 de septiembre escribí para avisarles que el enlace del sitio del elemento Wikidata cambiaría de lugar en el menú de la barra lateral, pasando de la sección General a la sección En otros proyectos . La fecha de lanzamiento programada para el 04.10.2024 se retrasó debido a una solicitud necesaria para el diseño Mobile/MinervaNeue. Me complace informarles que el lanzamiento global ahora puede continuar y ocurrirá más tarde hoy, 22.10.2024 a las 15:00 UTC-2. Háganos saber si nota algún problema o error después de este cambio. No debería haber necesidad de realizar ediciones nulas ni de purgar la caché para que se produzcan los cambios. Atentamente, -Danny Benjafield (WMDE) 11:29, 22 de octubre de 2024 (UTC) [ responder ]

El sitio está volviendo a funcionar en partes. Los servicios pueden funcionar, detenerse, reiniciarse, esto es lo esperado. Cada día se encienden más luces. Ver "El archivo de Internet más grande del mundo está bajo asedio y contraataca", The Washington Post , 18 de octubre de 2024 -- Green C 15:42, 22 de octubre de 2024 (UTC) [ responder ]

No estoy seguro de si este es el foro adecuado para esto, pero ¿es hora de retirar IPCheck? Sin duda aplaudo los esfuerzos de SQL a lo largo de los años, pero están esencialmente inactivos, la base de código ha estado congelada durante años y han aparecido cosas más nuevas como la herramienta de información de IP incorporada y Bullseye. Pero todavía tenemos IPCheck integrado en la interfaz en la parte inferior de las páginas de contribuciones de IP. RoySmith (discusión) 17:39, 22 de octubre de 2024 (UTC) [ responder ]

Se puede discutir en Plantilla discusión:Anontools . PrimeHunter ( discusión ) 18:07 22 oct 2024 (UTC) [ responder ]