Wikipedia:Café/Portal/Archivo/Técnica/2024/04

Añadir enlaces
De Wikipedia, la enciclopedia libre
Esto es un archivo de entradas pasadas. Por favor, no edites los contenidos de esta página. Si deseas comenzar una nueva discusión o continuar una antigua, por favor, hazlo en la página actual.


Noticias técnicas: 2024-14[editar]

Las últimas noticas técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Cambios recientes

  • Los usuarios de que activaron la opción de accesibilidad para la lectura notarán que la opción del alto de línea para texto normal y grande ha sido cambiada. [1]

Cambios de esta semana

  • La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 2 de abril. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 3 de abril y en todas las wikis a partir del 4 de abril (calendario). [2][3]

Cambios futuros

  • La Fundación Wikimedia posee un plan anual en el cual se decide en qué trabajará la Fundación durante el próximo año fiscal de Estados Unidos. Puedes leer un borrador de los resultados claves para el Departamento de Producto y Tecnología. Existen sugerencias de cuáles resultados desea la Fundación para los cambios técnicos entre los meses de julio de 2024 y junio de 2025. Puedes dejar tus comentarios en la página de discusión.

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 03:33 2 abr 2024 (UTC)

Wikidata weekly summary #622[editar]

Here's your quick overview of what has been happening around Wikidata over the last week. This is the Wikidata summary of the week before 2024-03-11. Translations are available.

Discussions

  • New requests for permissions/Bot: MONA.artpublic.bot (Task: The bot's function is to add information about artists specializing in public artwork in Québec, Canada. The bot will initially only add that an artist's genre of work is public art for a set of known public artists in Québec compiled by MONA Montréal from open data sets.)

Events

  • Upcoming:
    • Next Linked Data for Libraries LD4 Wikidata Affinity Group call April 2, 2024: Come join us for fun data modeling discussions! We'll create breakout rooms in Zoom for people to discuss 4 examples of cultural heritage items to contribute to Wikidata. Each group will choose categories, brainstorm properties for basic and enhanced description, and discuss challenges. Then we'll have some quality time at the end to compare notes and discuss our processes! Agenda
    • Wikidata Leveling Up Days, everything you need to know about Wikidata: 5, 6, 7, 12, 13 and 14 April. The event is taking place online and the videos are already available on the program page.

Press, articles, blog posts, videos

  • Blogs: Galerij der Groten op Wikidata (Dutch) - Wikimedia NL hosted an Edit-A-Thon on the Baroeg project, the task was to document and archive on Wikidata all of the bands that have played at the live music venue, the idea born from a stack of band flyers and posters hung in the bathroom(!) Join the next one Sunday April 14th.
  • Papers: Understanding Wikidata - Wikidata is extremely valuable as a data source to supplement, validate and extend existing knowledge bases and applications. To effectively utilize Wikidata in a Semantic Web application, one must understand its design, terminology and correspondence with ontological concepts (especially RDF and OWL). This paper attempts to explain and position this information. (by AWesterinen)
  • Videos
  • Notebooks: Gender differences in the number of sitelinks among members of the European Parliament, a statistical analysis based on Wikidata about the number of sitelinks by gender.

Tool of the week

  • Wikidatalite : Search, browse, and navigate Wikidata items with a mobile-friendly, simplified user interface.

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • mul language code: We are continuing the work on fixing remaining issues for the next stage of releasing it (phab:T356200)
  • REST API:
  • EntitySchemas: We continued work on making it possible to link to EntitySchemas in statements (phab:T359419)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

Plantilla de respuesta en los tablones[editar]

Buenas, tras haber comentado en el mail de los biblios y en IRC la mejora del formato de la respuesta en el tablón de bibliotecarios, paso por aquí más que nada por el motivo de PeriodiBot, que en caso de adoptar la inclusión de a plantilla en el formulario de nueva solicitud (preload), debería ser actualizado para no considerar archivable una respuesta con la plantilla vacía. Vuelvo a mencionar a aquí MarioFinale (que no ha estado muy activo últimamente ni contesta al mail), por si acaso. En cuanto a jembot, habiéndolo comentado con -jem- ningún problema ahí tampoco.

El uso de la plantilla en sí ha sido respaldado por los admins que han participado en la correspondencia, repito aquí en lo que consta: Con el fin de resaltar las respuestas de los bibliotecarios y dejar claro su carácter resolutorio en solicitudes/denuncias (y algún que otro motivo), usar la plantilla {{admintab}} en la sección de respuesta de cada entrada.

En un principio (en la fase de prueba) se aplicará manualmente en las respuestas de secciones del tablón que no se actualizan por jembot, o sea por los propios biblios (y los que no, ya se actualizará a continuación). Luego, cuando forme parte de los formularios de recarga, se podría incluir este texto en la sección de respuesta: 

<!--ESTA SECCIÓN SOLO PUEDE SER EDITATA POR BIBLIOTECARIOS-->
; Respuesta
{{admintab|1=
<!--Resolución-->
|2=<!--~~~~-->
}}

Se ha comentado la automatización de según qué datos, etc., pero esto para más adelante; los tags <!-- --> son más que nada para indicar a los biblios qué poner dónde, al menos al principio, si es más fácil dejar los parámetros en blanco, pues se hace. Cuando el primer parámetro está vacío (también si solo contiene este tag de comentario html) se genera el mismo aviso en paréntesis "a rellenar por un bibliotecario". La idea es que el bot lo considere como se considera el aviso de texto actual.

En todo caso, la prueba inicial es solo para acostumbrarse al formato y al uso de la plantilla.

En fin, un saludo.  νιяυм мυη∂ι @ ℓσg  07:06 16 mar 2024 (UTC)

Personalmente me parece estridente de más que las respuestas en el tablón de biblios pasen a estar dentro de un rectángulo color caqui y que se añada este texto bajo todas ellas, incluso para cuestiones rápidas y para nada polémicas:
Esta resolución es final, por favor no contestes a ella a menos que seas un bibliotecario. Si deseas abordar el tema de nuevo, crea una nueva entrada.
Me da la sensación de que se está dictando una sentencia judicial, y yo no me considero juez. De todas formas, es una cuestión menor y sé que ha tenido buena acogida entre otros biblios, solo quiero dejar aquí mi pequeño comentario en contra. sasha 10:54 16 mar 2024 (UTC)
Todas las opiniones son bienvenidas.... pero tampoco cambia nada en cuanto a procedimiento, siempre cuando alguien contesta a una resolución, su respuesta es revertida o, si el biblio está por la labor, movida a la sección de comentarios; y aquí no se trata de jueces, sino de una resolución administrativa, y creo que de esta forma parece más profesional además de informativo. En todo caso, para eso he abierto el hilo, para las distintas opiniones, sobre todo de admins (sobe el procedimiento) y de los que se dedican a temas técnicos (por lo del bot y cualquier otra aportación). Un saludo.  νιяυм мυη∂ι @ ℓσg  11:56 16 mar 2024 (UTC)
Primero coincido con -sasha- en relación a la coletilla final. Además que resultará demasiado repetitivo leerlo en todos y cada uno de los hilos cerrados, cuando con indicarlo en las instrucciones de la cabecera ya me parece más que suficiente.
Segundo, como colaborador junto a MarioFinale para la estandarización del archivado de discusiones y tablones, con el uso de la plantilla en principio no se archivarán los hilos, puesto que la condición para el archivado automático es que exista una firma con fecha al final del hilo (según la configuración |Estrategia=FirmaEnÚltimoPárrafo), y en este caso la última línea o párrafo contiene únicamente el cierre }} de la plantilla. Mi bot, por ejemplo, no será capaz de archivar estos hilos sin alguna pequeña reprogramación, y supongo que también será necesario adaptar el código de PeriodiBOT, quien se encarga actualmente del archivado automático.
Tercero, este cambio afectará también a la herramienta «Permite ocultar solicitudes ya atendidas en el TAB» (MediaWiki:Gadget-tab-oculta-atendidas.js), aunque quizás ya no importa mucho porque actualmente esta herramienta —entre otras varias— ya ha dejado de funcionar en la nueva piel Vector (2022) —gracias a los desarrolladores e impulsores de dicha piel, a quienes no les han importado mis reclamaciones al respecto—. Sin embargo sí continúa funcionando de momento en la piel Vector (2010), por lo que quizás alguien todavía la usa.
Pese a todo, por favor, Virum Mundi, documenta el uso de la plantilla {{admintab}} para que todos entendamos su funcionamiento. -- Leoncastro (discusión) 13:37 16 mar 2024 (UTC)
En otros proyectos este tipo de avisos tienen una redacción algo más neutra y menos infantilona. Por ejemplo en Wikimedia Commons:
"The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion."
Al contrario que -sasha- no puedo hablar de cómo se consideran a sí mismos los administradores en este proyecto, pero lo de las palabras "resolución" o la negrita y subrayado en "es final." tiene ligeras trazas del tono condescendiente, y a la vez autoritario y, también, reverencial para con los usuarios con el flag de administrador, del que otros proyectos carecen. Un saludo. strakhov (discusión) 13:37 16 mar 2024 (UTC)
@Strakhov: el texto puede adaptarse. Un saludo.  νιяυм мυη∂ι @ ℓσg  14:35 16 mar 2024 (UTC)
@Leoncastro La documentaré o la eliminaré según sea el caso. Un saludo.  νιяυм мυη∂ι @ ℓσg  14:30 16 mar 2024 (UTC)
En cuanto a PeriodiBot, como habrás leído en la presentación, es el motivo principal de abrir este hilo y no proceder directamente a la fase de pruebas.  νιяυм мυη∂ι @ ℓσg  14:33 16 mar 2024 (UTC)
@Virum Mundi, fase de pruebas iniciada. No creo que haga daño a nadie. -- Leoncastro (discusión) 16:25 16 mar 2024 (UTC)

Sí, ya... puede adaptarse, como todo aquí... El caso es que ahora dice lo que dice y, sobre todo, lo hace de la manera en que lo hace, en consonancia con la tradición "hispana" de los mensajes autoritarios y terminantes, las órdenes, los imperativos, el principio de autoridad y el perdonavidismo general, ya sea en escritos personalizados por los propios usuarios o incluso en el texto prefabricado de plantillas de aviso. Una alternativa más neutra podría ser esta:

El hilo anterior está cerrado. Por favor no lo modifiques. Si consideras conveniente reabrir este tema, puedes iniciar un nuevo apartado al final.

Saludos. strakhov (discusión) 16:40 16 mar 2024 (UTC)

Esta por contra es menos neutra, es un poco una parodia del estilo comunicativo de es.wikipedia:

Esta resolución es final. Continuar escribiendo aquí está No terminantemente prohibido salvo que seas bibliotecario, y si editas la sección puedes acabar denunciado por ediciones arbitrarias o vandalismo, lo que puede conducir al bloqueo de tu cuenta. Si quieres reabrir el tema, abre otro tema nuevo. Un cordial saludo.

Saludos. strakhov (discusión) 16:57 16 mar 2024 (UTC)

"Un cordial saludo" 🤭
Si me permiten una opinión adicional, la plantilla de cierre de sección en Wikidata incluye la firma al final; quizá sea una opción para no tener que hacer tantos ajustes al bot. –FlyingAce✈hola 17:44 16 mar 2024 (UTC)
@Virum Mundi, el bot archiva normalmente los hilos cerrados, y respeta sin archivar los hilos sin cerrar. -- Leoncastro (discusión) 01:12 17 mar 2024 (UTC)
Gracias @Leoncastro.
@FlyingAce: yo no veo que esta plantilla se ajuste a lo que estamos buscando (y digo estamos pues era una idea compartida, y tampoco se ve reflejado en este hilo la buena acogida entre los admins que han participado en la correspondencia interna).  νιяυм мυη∂ι @ ℓσg  16:10 17 mar 2024 (UTC)
@Virum Mundi: yo lo decía más por la estructura (primero el texto y al final la firma) pero en vista de que el bot sí archiva el hilo con la plantilla actual, no sería necesario modificarla. En cuanto al texto en sí, me agrada esta alternativa que propone Strakhov. –FlyingAce✈hola 16:15 17 mar 2024 (UTC)
Reafirmo mi apoyo, concuerdo con las sugerencias para cambiar la línea final (y con la reflexión general de que nuestro estilo comunicativo resulta demasiado áspero), y estoy dispuesto a hacer más ajustes en mi bot (aunque en este caso no parece necesario) y en general a plantear reformas más en profundidad en los tablones que simplifiquen tanto las consultas como las respuestas, sobre todo para asegurar que el wikitexto queda formateado correctamente y facilitar así la programación de todos los bots o herramientas que deban trabajar en ellos (seguramente habría que empezar por implantar formularios). Lo he comentado ya en el pasado, es una tarea imprescindible para el futuro y espero que más usuarios y particularmente bibliotecarios se quieran ir implicando. - José Emilio –jem– Tú dirás... 20:27 29 mar 2024 (UTC)

┌─────────────────────────────┘
Hola, primero que todo mis disculpas por no responder. He estado extremadamente ocupado y fuera de casa (y del país) estos meses. Hace poco regresé y estoy poniéndome al día con los miles asuntos pendientes que tengo. No tengo problema en hacer los cambios en mi bot (Aunque no entiendo muy bien que cambios debiera hacer, ya que el bot en teoría solo busca que la sección sea firmada). Quedo a la espera de una decisión formal. ~ℳɑrio - (¿Un té?) 08:42 30 mar 2024 (UTC)

Sobre esto no tienes que hacer ningún cambio MarioFinale. Como ya demostré anteriormente, tu bot archiva normalmente los hilos cerrados y respeta sin archivar los hilos sin cerrar cuando incluyen esta nueva plantilla. -- Leoncastro (discusión) 15:11 30 mar 2024 (UTC)

comentario Comentario Por favor, modifiquen la plantilla para que no suene tan "agresiva" o "autoritaria" o "infantil" como dicen pero es necesaria, sobretodo para los novatos que insisten en replicar en el tablón las resoluciones y para saber cuando está cerrado el tema y no tener que estar perdiendo el tiempo revirtiendo en el tablón. Es cierto que el uso de la plantilla tuvo consenso entre los biblios que han participado en los correos. Me parece bien la propuesta de strakhov. --Jalu (discusión) 02:35 31 mar 2024 (UTC)

  • Pregunta: ¿Existe alguna política que prohiba comentar o contraresponder un hilo del TAB ya resuelto? Por que no faltan los casos en que algún usuario no esté de acuerdo con alguna resulución (especialmente en csos controvertidos) o simplemente un agradecimiento ¡un agradecimiento!, y que dicha edición es revertida incluso por no-bibliotecarios. Creo que debería empezarse por ahi. --Amitie 10g (discusión) 02:41 31 mar 2024 (UTC)
✓ Respuesta: El TAB es para que resolvamos los bibliotecarios, no para hacer un intercambio de si estamos o no de acuerdo como usuarios. Para eso están las discusiones. Saloca (ངའི་གླེང་མོལ།) 02:43 31 mar 2024 (UTC)

┌─────────────────────────────┘
 Hola a todos y gracias por vuestras opiniones (como también las opiniones en la lista de bibliotecarios, los mails y en las PD de usuario). Las últimas dos semanas algunos hemos probado el uso de la plantilla, que repito - puede modificarse, no tengo firmado ningún contrato de derechos reservados con este diseño. La última modificación del comentario debajo de la firma fue por sugerencia de un admin, pero tampoco está grabado en piedra. Creo que se podría ir planteando su uso en general en las próximas semanas, y luego decidir.

En cuanto a lo que dice -jem- con respecto a plantear "reformas más en profundidad en los tablones que simplifiquen tanto las consultas como las respuestas", ya mencioné en su día que creo que en pleno 2024 podríamos contar con una versión más "WYSIWYG", un pop-up con un formulario para rellenar, pues no todo el mundo entiende de programación ni tiene experiencia con wikitext para entender lo que significan los corchetes y las llaves, y en todo caso, como en otros sistemas mucho menos extendidos que Wikipedia, lo lógico sería un formulario "normal" para rellenar directamente.

Un saludo.  νιяυм мυη∂ι @ ℓσg  12:14 3 abr 2024 (UTC)

Gracias, @Virum Mundi, me gustaría comentar algunas cuestiones sobre la plantilla:
  • Teniendo en cuenta que @PeriodiBOT archiva los hilos cuando existe una firma en la última sección, es posible que existan casos en los que el bot archivará una solicitud en proceso (cuando el valor del primer parámetro de {{admintab}} es 0), ya que, según la documentación de la plantilla, en esta situación también se incluye la firma del bibliotecario.
  • En múltiples ocasiones, en las resoluciones de un tablón se ha llamado a otros bibliotecarios a participar. Me parece una opción sana si el bibliotecario necesita opiniones de terceros para tomar una decisión o si prefiere tomarla en base a un consenso. Para estos casos la plantilla no ofrece ningún tipo de opción. Como solución a esto (y esto es tan solo una idea), quizás podría implementarse un parámetro obligatorio específico que indicase el estado de la resolución («pendiente», «en proceso», «finalizada»; o simplemente «0», «1» y «2»), los bots y scripts podrían modificarse fácilmente para que reconociesen ese parámetro en lugar de la firma.
  • Como probablemente sabes, existe una cantidad importante de usuarios que utilizan WP:TL para realizar labores de mantenimiento. A día de hoy, cuando la herramienta deja un mensaje en un tablón, esta completa la última sección con el texto «(a rellenar por un bibliotecario)». Ya que parece haber cierto consenso para el uso de la plantilla por parte de los bibliotecarios, quizás sería más cómodo que dejase {{admintab|1=|2=}} en su lugar. Sin embargo, he observado que no todos los bibliotecarios han manifestado pretender hacer uso de la plantilla.
Respecto a lo que comentas de simplificar las respuestas a través de formularios: desde el lado de las consultas ya existe WP:TL para muchas de las solicitudes que se llevan a cabo en los tablones; para los bibliotecarios se puede implementar fácilmente un script parecido que deje una respuesta a través de un pequeño formulario, pero es más fácil de llevar a cabo si existe una estandarización adecuada. Nacaru · Discusión ✉ · 15:06 3 abr 2024 (UTC)

Ficha de mar lunar[editar]

Buenas. Noté que todas las fichas de mares lunares están arrojando un error de coordenadas. Ejemplo Mare Imbrium, Lacus Spei y calculo que todos los artículos contenidos en Categoría:Mares de la Luna. ¿Alguien sabrá como corregirlo? No conozco mucho el funcionamiento de las plantillas, pero parece que viene al interpretar las coordenadas de Wikidata. Saludos. ile🍂 (discusión) 01:01 3 abr 2024 (UTC)

Arreglado. sasha 01:19 3 abr 2024 (UTC)
Muchas gracias! ile🍂 (discusión) 02:34 3 abr 2024 (UTC)

Evitando avisos de conflicto de edición[editar]

Cuando se usa una página de preload con section=new. ¿Alguna idea? No sé por qué ocurre. Un saludo.  νιяυм мυη∂ι @ ℓσg  08:51 3 abr 2024 (UTC)

Eliminar espacios vacíos en una table/wikitable[editar]

Diagrama Walter Lieth para la ciudad de Ovalle.
Diagrama Walter Lieth para la localidad de Puquios.
Diagrama Walter Lieth para la localidad de Carrizal.

Como se pueden eliminar los espacipos vacíos (a la derecha y bajo las imágenes) de esta tabla?. Nótese que en la previsualización, en Código y en cuenca del río Limarí#Clima aparecen tres diferentes visualizaciones. Me interesa el resultado en el artículo. Juan Villalobos (discusión) 13:06 8 abr 2024 (UTC)

OK, encontré el error: falta(ba) un "|centro|" entre los paramétros de cada archivo. De todas maneras, gracias.--Juan Villalobos (discusión) 15:37 8 abr 2024 (UTC)

Noticias técnicas: 2024-15[editar]

Las últimas noticas técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Cambios recientes

  • Navegadores web pueden usar herramientas llamadas extensiones. Existe una extensión en Chrome llamada Citation Needed (Cita requerida) la cual puede ser usada para ver si una afirmación en línea está avalada por un artículo en Wikipedia. Este es un experimento a pequeña escala para ver si Wikipedia puede ser usada en de esta forma. Debido a que es un experimento pequeño, solo puede ser usada en Chrome en inglés.
  • Una nueva característica de Edit recovery (recuperación de edición) ha sido añadida a todas las wikis, disponible como una preferencia de usuario. Una vez habilitada, tus ediciones en curso serán almacenadas en tu navegador web, y si accidentalmente cierras la ventana de edición o tu navegador o el computador deja de responder, te preguntará si deseas recuperar el texto sin publicar. Agradecemos cualquier retroalimentación en la página de discusión del proyecto. Este pedido era el número 8 de la Lista de Deseos de la Comunidad 2023.
  • Los resultados iniciales de los experimentos de Edit check han sido publicados. Edit Check ya se encuentra disponible como característica por defecto en las wikis donde fue probada. Coméntanos si tu wiki quiere ser parte del siguiente lanzamiento de Edit check. [4][5]
  • Las personas que usan la piel (skin) Minerva en dispositivos móviles notarán que se han hecho mejoras en el alto de línea en todas las tipografías. [6]

Cambios de esta semana

  • La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 9 de abril. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 10 de abril y en todas las wikis a partir del 11 de abril (calendario). [7][8]
  • Las nuevas cuentas de usuarios y usuarios no registrados tendrán activado por defecto el editor visual en la versión móvil. Este lanzamiento se realizará para todas las wikis excepto para la Wikipedia en inglés. [9]

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 23:34 8 abr 2024 (UTC)

Noticias técnicas: 2024-16[editar]

Las últimas noticas técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Problemas

  • Entre el 2 y 8 de abril, las páginas que usan Ediciones revisadas, la etiqueta "Revertido" no fue aplicada para las ediciones deshechas. Adicionalmente, las páginas movidas, protegidas e importaciones no fueron revisadas automáticamente. Este problema ya fue resuelto. [10][11]

Cambios de esta semana

  • La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 16 de abril. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 17 de abril y en todas las wikis a partir del 18 de abril (calendario). [12][13]
  • Las claves de ordenamiento por defecto ahora afectan a las categorías añadidas por plantillas en las notas al pie. Anteriormente las notas al pie usaban el título de la página como clave de ordenamiento por defecto incluso si existía otra clave de ordenamiento (las claves de ordenamiento por categoría ya están funcionando así). [14]
  • Una nueva variable page_last_edit_age será añadida al filtro antibusos. Indicará cuántos segundos han pasado desde la última edición a una página. [15]

Cambios futuros

  • Los desarrolladores voluntarios deberán actualizar el código de sus herramientas y opciones para manejar cuentas temporales. Lea más acerca de esto.
  • Cuatro campos de la base de datos serán eliminados de las réplicas de base de datos (incluyendo Quarry). Esto afectará solamente a las tablas abuse_filter y abuse_filter_history. Algunas consultas podrían requerir una actualización. [16]

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 23:26 15 abr 2024 (UTC)

Artículos con identificadores VcBA / Artículos con identificadores BNB[editar]

Observo de modo masivo en rojo categorizados Artículos con identificadores VcBA: [17] y Artículos con identificadores BNB: [18], entre otras categorías. Dado que llevan tiempo sin resolución, pongo en conocimiento por si ha quedado algo sin hacer y/o alguien ha errado y ha dejado todo patas arriba. A quien corresponda técnicamente. Xabier (discusión) 19:17 16 abr 2024 (UTC)

Viene del modulo de control de autoridades, coincide con la edición reciente de Vanbasten 23. Me imagino que falta crear las categorías, y luego ocultarlas. Anibal Maysonet (discusión) 19:26 16 abr 2024 (UTC)
strakhov hizo esas dos y yo otra que faltaba y creo que ya están todas. Un saludo. --vanbasten_23 (discusión) 21:43 16 abr 2024 (UTC)

Tabular data como fuente[editar]

Hola. Veamos. Se me ha ocurrido que sería interesante importar los datos de población de los 131 barrios de Madrid a las fichas de Wikipedia. Sin embargo, la "licencia" que tienen no deja muy claro que sea compatible con la CC0 de Wikidata (piden p. ej. atribución). En Commons se pueden asignar más licencias. Lo de no desnaturalizar no equivale a no modificar, por cierto. Los he descargado. Los he nombrado por su respectivo Q. He probado a subir los datos a Commons (muy fácil, se pueden importar automáticamente archivos excel como JSON). He importado acá desde en.wiki el módulo en:Module:Tabular data, que permite hacer lookups en celdas. Y he hecho la prueba en un barrio. Y... funciona. ¿A alguien se le ocurre si algo así sería sistematizable con una ficha? Entiendo que habría que sistematizar la sintaxis de los nombres de los archivos de Commons y posiblemente asignar mediante alguna clase (¿de wikidata? ¿Q10267336?) el set de datos a utilizar. ¿Podría hacer falta un módulo para esto? strakhov (discusión) 22:11 31 mar 2024 (UTC)

comentario Comentario un par de links se actualizaron a posteriori. strakhov (discusión) 17:20 2 abr 2024 (UTC)
Por fin sale este tema. Los datos tabulados de Commons me parecen una manera excelente de guardar material que no es apropiado para Wikidata ya sea por su licencia o extensión, además de estar más a salvo del vandalismo. Como se alojan en Commons también están centralizados y se pueden actualizar periódicamente, con bots por ejemplo. Tengo entendido que en en.wiki se usaron para datos de infectados y fallecidos en la última pandemia porque los elementos de Wikidata eran casi inmanejables. De momento he creado {{Búsqueda dato tabulado}} para poder usar la función lookup sin tener que invocar directamente el módulo. Con respecto al tema «barrios de Madrid» se puede hacer lo siguiente:
  • Insertar la plantilla {{Búsqueda dato tabulado}} en el parámetro población= de los 131 artículos correspondientes (tedioso, sería necesario vigilar que ningún despistado los retire).
  • Modificar la {{Ficha de entidad subnacional}} para que obtenga los datos de población de la tabla correspondiente cuando el artículo sea una instancia de (P31) barrio administrativo de Madrid (Q10267336). Se podría incluso crear un módulo (¿Módulo:Población de entidad subnacional?) para esto si hubiera que manejar muchos conjuntos de datos. Sería similar a las plantillas de datos que se manejaban antes de que existiese Wikidata. Por otra parte, no sé si merece la pena modificar una ficha con más de 100 000 transclusiones por (de momento) 131 artículos.
  • Crear una plantilla {{Ficha de barrio de Madrid}} que haga de wrapper de la ficha de entidad subnacional, tomando de ella los parámetros que se consideren necesarios con la peculiaridad de que la población= la obtendrá de la tabla correspondiente. Va contra la filosofía de esta Wikipedia de «cuantas menos plantillas, mejor», pero no veo que suponga realmente una carga extra de mantenimiento puesto que el grueso del código permanece en la ficha original y la nueva sería un apenas un «cascarón». En general, pienso que los wrapper están desaprovechados en esta Wikipedia y me parecen la solución más sencilla a problemas recurrentes como los parámetros a mostrar, por ejemplo en la {{Ficha de persona}}. Si volviésemos a tener una {{Ficha de científico}} o {{Ficha de modelo}} con este sistema (de hecho, así es en en.wiki) se ahorraría en mantenimiento (todo seguiría en módulo correspondiente, en realidad), pudiendo adaptarse mejor a profesiones concretas.
  • Una combinación de los dos puntos anteriores. Por ejemplo, si tenemos un wrapper llamado {{Ficha de entidad subnacional de España}} (ninguna locura teniendo en cuenta que existe una {{Ficha de localidad de España}}), se podría hacer que tomase la población de varias tablas que tuviesen la información de los barrios, municipios, localidades... y en su defecto, que se cogiesen de Wikidata como hasta ahora.
En cualquier caso, estas son solo varias ideas rápidas de cosas que se pueden hacer con los datos tabulados en nuestras fichas y la solución más apropiada dependerá del caso concreto. sasha 16:34 1 abr 2024 (UTC)
Bueno, una parte de estos artículos usan {{ficha de barrio}}, que tiene unos poquitos usos menos que {{ficha de entidad subnacional}} (su destino a medio plazo posiblemente sea terminar fusionado con esta).
En cuanto a la opción de incluir "búsqueda de dato tabulado" en los artículos, el problema que le veo es que dentro de un año habría que volver a cambiar 131 veces en las fichas el archivo de datos donde buscar (o la columna, si se agregaran en la misma tabla). Mi idea era intentar que hubiera un lugar centralizado donde poder, como dices tú en relación p. ej. con la existencia en Wikidata de una determinada declaración, asociar a un grupo de artículos un... archivo de destino concreto de datos de población. Esto es, una edición cada año, o incluso automatizarlo del todo para utilizar la fecha más reciente de una tabla única, si se pudiera. En cualquier caso, si se creyera que esto es útil, sería interesante definir unos nombres estandarizados (y estructura) en Commons para estas tablas demográficas.
En cuanto a los wrappers, no tengo una opinión muy formada, puede ser interesante, pero antes de nada creo que convendría unificar un poco el tema fichas en este set de artículos (me di un paseo y estaba todo un poco manga por hombro, poca coherencia interna).
Por otra parte creo que esto tiene también cierto potencial para las tablas de clima (precipitaciones mensuales, temperaturas, etc), entre otros aspectos. Un saludo. strakhov (discusión) 16:48 1 abr 2024 (UTC)
Otra opción es crear una ficha de cero (que seguramente también vaya en contra del "cuanto menos plantillas, mejor" xD). strakhov (discusión) 16:50 1 abr 2024 (UTC)
Yo hace tiempo que he llegado a la conclusión de que muchas de nuestras principales y más grandes plantillas o módulos (de persona, de país, de entidad subnacional, ...) necesitan un reset para ser rediseñadas desde cero. No solamente para ser más eficientes, sino también para dejar de ser un rompecabezas de múltiples piezas muy distintas tipo monstruo de Frankenstein, tanto en su código interno como en algunas veces en su estilo visual. Es necesario hacer plantillas y módulos modulables —valga la redundancia—, fácilmente expandibles y configurables. Y si se puede mejorar la importación de Wikidata y Commons, mejor. Y hacerlos de cero no tiene que ir en contra del «cuanto menos plantilla, mejors», sino que se puede hacer directamente en los propios módulos existentes, tal como hace años hice con el Control de autoridades. -- Leoncastro (discusión) 17:08 1 abr 2024 (UTC)
c:Data:Madrid-neighborhoods-population by year.tab. Ahora están todos los datos desde 2018. Si se crea una nueva ficha de cero aparte, si el resultado fuera exitoso siempre podría terminar sustituyendo a la(s) antigua(s) dentro del código (por fusión). El problema de plantear la reforma total directamente dentro de la antigua es que uno depende de la no aparición de quejas, los "consensos", los "mamita-vamos-a-quedarnos-como-estamos", los "en-contra", etc. Yendo, digamos, por libre ...se tienen las manos menos atadas. Pero bueno, yo no me veo capacitado para esas cosas, hablo un poco por hablar. A lo máximo a lo que aspiro en estos momentos es a crear una plantilla sencillita tipo {{población barrio madrid}} usando estos lookups para insertarla en las fichas de estos 131 artículos e irla actualizando cada año. :D strakhov (discusión) 17:49 1 abr 2024 (UTC)
comentario Comentario En cualquier caso, ¿sería fácil parchear {{ficha de barrio}} para que cuando se incluyan datos locales para |población= no se muestre la fecha tomada de wikidata en |población_año=, que no tiene por qué corresponderse con la del dato local? strakhov (discusión) 18:37 1 abr 2024 (UTC)
@Strakhov, creo que me he perdido: de momento la ficha de barrio no está importando de Wikidata ni la población ni el año. -- Leoncastro (discusión) 19:37 1 abr 2024 (UTC)
@Leoncastro, perdona mi error, yo también me perdí. Efectivamente, la que está haciendo eso no es {{ficha de barrio}} sino {{ficha de entidad subnacional}} (la que sale en el artículo de Legazpi). Además, al importar la fecha completa con día y mes, unido al formato que se le da, hace que quede horrendo, pero eso ya es secundario (de hecho tiene un formato menos disonante la ficha de barrio, véase El Pilar). strakhov (discusión) 20:01 1 abr 2024 (UTC)
Oferta 2×1. -- Leoncastro (discusión) 20:17 1 abr 2024 (UTC)
Muchas gracias. Pasaré a implantar mi pequeña chapuza ({{Población barrio Madrid}} y {{Año población barrio Madrid}}) para estas fichas de barrios madrileños. Bastará con actualizar el archivo de Commons el próximo año y cambiar 2023 por 2024 en ambas plantillas. Aunque, como dices, lo mejor sería una ficha flexible y versátil (y quizás más minimalista que las actuales) creada de cero, sin herencias, vicios ni cachivaches del pasado. Pero bueno. Un saludo. strakhov (discusión) 20:23 1 abr 2024 (UTC)
Por cierto, en {{ficha de entidad subnacional}} habría que implantar que cuando hay datos locales ...la densidad de población la calcule con el valor local (y con la superficie local, ya puestos). Es que es parche tras parche. Es desesperante, efectivamente, haría falta empezar de cero. strakhov (discusión) 20:35 1 abr 2024 (UTC)

He hecho una prueba con los municipios de España. {{Población municipio España}}. Funciona perfectamente tras cargar los datos a Commons desde el archivo descargable en la página del INE con licencia CC BY 4.0 (aunque con el fin de abreviar he aprovechado el dato del código del INE almacenado en Wikidata (P772 para relacionar con los artículos de Wikipedia), lo que hace a la plantilla más susceptible a ataques, por contar con ese intermediario y no trabajar directamente con Commons). Digo yo que es más fácil y rápido esto que trocear los datos en cada ítem de WD. strakhov (discusión) 21:16 6 abr 2024 (UTC)

Esto también puede tener potencial con estadísticas de ...¿baloncesto? (LeBron_James#Temporada_regular). Un saludo. strakhov (discusión) 21:16 6 abr 2024 (UTC)

Efectivamente, este es un tema interesante e importante en el que tenemos que intentar pensar a largo plazo y con una perspectiva amplia. Quedan todavía en muchos municipios de España datos de población a mano, o llamadas a plantillas obsoletas, etc., que es trabajo (abundante) para un bot, y deberíamos pensar ya en un sistema más definitivo, que requiera actualizar datos pero no código, y compatible con otros países. Los datos de población los ha estado actualizando Kizar con su bot en Wikidata, anualmente y elemento por elemento, y partiendo de que tiene todo el sentido usar datos tabulados, también parece claro que no podemos dejar desactualizados los elementos, o al menos no durante muchos años, por lo que habrá que consensuar al menos estas cuestiones de actualización, ya sea en Wikidata, Commons o Meta. Y por supuesto que habrá que pensar en soluciones similares para todo tipo de estadísticas variables, ya sean climáticas, deportivas... Apoyo también cualquier reinicio desde cero que se necesite para dejar las cosas bien hechas. Espero que podamos implicarnos y coordinarnos todos los de perfil técnico para abordar estas cuestiones. - José Emilio –jem– Tú dirás... 20:05 20 abr 2024 (UTC)

Aunque se escape un poco del tema de este hilo, de cara a una posible nueva 'ficha de lugares' hecha desde cero, cosas interesantes que podrían tenerse en cuenta serían:

  • Dar cierta homogeneidad al tema de mapas. Posible agrupamiento de varios mapas estáticos mediante un switch. Inclusión automática de un mapa dinámico. (véase hilo relativamente reciente relacionado)
  • Especialización interna mediante esos wrappers (mencionado arriba) asociados a ítems concretos de Wikidata (entidad federativa de México, municipio de España, comuna de Francia, comune de Italia, barrio administrativo de Madrid, condado del Reino Unido, departamento de Colombia). Esto podría tener relevancia tanto para:
  • Existencia de parámetros de ubicación específicos para cada tipo de lugar (comunidad autónoma, departamento, provincia, comarca, parroquia, municipio, comuna, etc), cuyos datos recomendaría no borrar localmente (el proceso para extraer la "cadena" completa a partir de la propiedad P131 desde Wikidata [donde sólo se ha de colocar la entidad administrativa inmediatamente superior] es un shitshow y da muchísimos fallos y problemas, además de que varios parámetros relativos a ubicación no se corresponden exactamente con "entidades administrativas" o al menos no está así entendido en Wikidata (comarca, partido judicial, mancomunidad, etc).
  • Existencia de parámetros de jefe de gobierno con nombres específicos (alcalde, presidente, regidor, etc).
  • La fuente a usar para los datos demográficos (algunas clases podrían establecer tomar datos de Wikidata y otras de Wikimedia Commons, según dónde se estén subiendo). (véase este hilo).
  • Para colocar en "el subtítulo" el tipo de entidad (veánse problemas recientes con subclases en Wikidata que conducen a cierta falta de congruencia interna en es.wiki).
  • Evaluar una posible desaparición de mini-banderitas (dejar sólo las relativas a la entidad de población en sí) y/o cabeceras.
  • Evaluar quizás recortar el número de parámetros rellenables (hay algunos posiblemente anecdóticos).
  • Resolver el tema de los topónimos en otros idiomas y/o alfabetos en la parte superior de las fichas. Véanse hilos como este o este otro, relacionados en mayor o menor medida.

Como siempre digo, no sé cómo y dónde y quién va a consensuar qué con quién fuera de este proyecto (?). Un saludo. strakhov (discusión) 11:41 21 abr 2024 (UTC)

Tech News: 2024-17[editar]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 April. It will be on non-Wikipedia wikis and some Wikipedias from 24 April. It will be on all wikis from 25 April (calendar). [20][21]

Future changes

  • This is the last warning that by the end of May 2024 the Vector 2022 skin will no longer share site and user scripts/styles with old Vector. For user-scripts that you want to keep using on Vector 2022, copy the contents of Especial:MiPágina/vector.js to Especial:MiPágina/vector-2022.js. There are more technical details available. Interface administrators who foresee this leading to lots of technical support questions may wish to send a mass message to your community, as was done on French Wikipedia. [22]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:25 22 abr 2024 (UTC)

Growth News, April 2024[editar]

El equipo de Crecimiento (Growth) enviará ahora informes trimestrales para mantener a la comunidad informada. Si quieres saber más sobre nuestro trabajo diario, las actualizaciones semanales del equipo de Crecimiento se encuentran disponibles en la wiki (en inglés).

Si deseas recibir actualizaciones más generales sobre la actividad técnica que tiene lugar en el movimiento Wikimedia (incluido el trabajo de Growth), te animamos a subscribirte a Tech News.

Configuración de la comunidad[editar]

Las funcionalidades de Crecimiento son actualmente configurables en Special:EditGrowthConfig. Este trimestre estamos trabajando en hacer Configuración de la Comunidad accesible para otras personas desarrolladoras de MediaWiki mientras que movemos la configuración de las funcionalidades de Growth a la nueva extensión CommunityConfiguration.

Una primera versión de Configuración de la Comunidad puede probarse en Spanish Beta Wikipedia. Planeamos lanzar la nueva extensión de Configuración de la Comunidad en las wikis piloto (Wikipedia en árabe y español) a principios de mayo de 2024. La primera funcionalidad no perteneciente al equipo de Crecimiento que utilizará la Configuración de la Comunidad será Automoderador.

En paralelo al desarrollo, el equipo de Crecimiento propondrá directrices de uso de la Configuración Comunitaria, directrices de diseño de la Configuración Comunitaria y proporcionará documentación técnica.

Resultados del Experimento[editar]

Análisis de los resultados de Añadir una imagen

El equipo de Crecimiento realizó un experimento para evaluar el impacto de la tarea estructurada "Añadir una imagen" en el módulo "Sugerencias de edición" de la página de inicio para personas recién llegadas. Este análisis revela que la tarea estructurada "Añadir una imagen" aumenta la participación de quienes acaban de llegar a la plataforma web móvil, sobre todo al realizar modificaciones constructivas (no revertidas) en los artículos:

  • La probabilidad de que las personas novatas de la web móvil editen su primer artículo (+17,0% respecto a la cifra de referencia).
  • La probabilidad de que se les retenga como recién llegados/as (+24,3% sobre la cifra de referencia).
  • El número de ediciones que realizan durante sus dos primeras semanas en la wiki (+21,8% respecto a la cifra de referencia).
  • Una menor probabilidad de que se reviertan las ediciones de las personas novatas (-3,3% sobre la cifra de referencia).

Resultados del experimento de Agradecimientos personalizados

Esta funcionalidad se desarrolló para personas Mentoras como parte del proyecto de Refuerzo positivo del equipo de Crecimiento. Al realizar pruebas A/B en Wikipedia en español, no encontramos ningún impacto significativo en la retención, pero sí un impacto positivo significativo en la productividad de las personas recién llegadas. Sin embargo, llegamos a la conclusión de que los resultados no eran lo suficientemente positivos como para justificar la inversión de tiempo de las personas mentoras. Tenemos previsto debatir esta función con nuestras wikis piloto y estudiar nuevas mejoras antes de ampliarla. Mientras tanto, las comunidades que deseen probar la función pueden solicitar su activación. (T361763)

Invitación a editar a quienes donan en la wiki en inglés

Como en años anteriores, las personas donantes fueron dirigidas a una página de agradecimiento tras la donación (ejemplo). Sin embargo, este año probamos una nueva llamada a la acción "Intenta editar Wikipedia" en la página de agradecimiento. Esta llamada a la acción enlazaba con una [página de creación de cuenta única https://en.wikipedia.org/w/index.php?title=Special:CreateAccount&geEnabled=1&campaign=typage-in-en-2023]. Desde esta página de creación de cuenta pudimos realizar un seguimiento de los registros y la activación (primera edición). Durante la campaña de banners en inglés, la página de agradecimiento al donante generó 4.398 cuentas nuevas, y 441 de ellas se editaron constructivamente en 24 horas. (T352900)

Trabajo futuro[editar]

Plan Anual

El equipo de Crecimiento y el de Edición trabajarán en el WE1.2 Key Result durante el próximo ejercicio. En breve entablaremos conversaciones iniciales con las comunidades para ayudar a ultimar nuestros planes. (T361657)

Página de inicio para personas recién llegadas Módulo de Actualizaciones de la Comunidad

Tenemos previsto realizar pruebas A/B para añadir un nuevo módulo configurable por la comunidad a la página de inicio para personas recién llegadas que permitirá a las comunidades destacar eventos, proyectos, campañas e iniciativas específicas. Estamos en la etapa inicial de la fase de planificación de este proyecto que tendrá lugar primero en nuestras wikis piloto y las wikis voluntarias. Agradecemos los comentarios de la comunidad sobre los diseños y planes iniciales, que nos gustaría recibir en cualquier idioma en nuestra página de discusión del proyecto.

Boletín del equipo Growth preparado por el equipo Growth y publicado por bot • Dar respuesta • Subscribirse o desuscribirse.

18:55 23 abr 2024 (UTC)

Enlaces a mediawiki desde las etiquetas[editar]

Hola. Tomemos como ejemplo la etiqueta Tarea para novatos. Ésta enlaza a mw:Special:MyLanguage/Help:Growth/Tools/Newcomer_Tasks. Si sigo el enlace y estoy logueado en MediaWiki, me lleva a la página de ayuda en castellano. Si no, a la página original (en inglés).

Ahora, no creo que la mayoría de los usuarios esté logueado en MediaWiki. Y si se loguean, no estoy seguro de que su idioma de MediaWiki sea español por defecto. Pero quizás MediaWiki muestre las páginas adecuadas si el usuario está en un país de habla hispana. Yo no puedo comprobarlo porque actualmente estoy en el extranjero.

¿Podría alguien (que viva en Hispanoamérica y no esté logueado en MediaWiki) clicar el enlace de arriba y decirme si la página está en inglés?

De ser así, cambiaría los enlaces de este tipo sacándoles el Special:MyLanguage/ y agregándoles /es.

Por ejemplo, mw:Help:Growth/Tools/Newcomer_Tasks/es.

Ping a Leoncastro (disc. · contr. · bloq.) que es el experto en estas cosas. Saludos. --angus (msjs) 20:36 26 abr 2024 (UTC)

PD: es debatible adónde tendrían que enlazar las etiquetas, pero por ahora quisiera restringir la discusión a la parte técnica de si mw:Special:MyLanguage realmente funciona. --angus (msjs) 20:53 26 abr 2024 (UTC)

Si sigo el enlace con mi sesión iniciada llego a la página en castellano y si no, a la página en inglés. Saludos. Lin linao ¿dime? 21:06 26 abr 2024 (UTC)
Gracias. Hablamos de sesión de MediaWiki, ¿no? --angus (msjs) 21:15 26 abr 2024 (UTC)
Confirmo, si no he iniciado sesión en MediaWiki llego a la página en inglés. Ahora bien, en teoría debería iniciarse sesión de forma automática, pero si el navegador está configurado para bloquear cookies de terceros, puede que no reconozca que "es.wikipedia.org" y "mediawiki.org" son parte de lo mismo y no guarde el inicio de sesión entre un sitio y otro. –FlyingAce✈hola 21:24 26 abr 2024 (UTC)
Sí. Con mi sesión soy Lin linao y veo el contenido en castellanoby también la interfaz, de acuerdo a mis preferencias. Al cerrar sesion sale todo en inglés. Saludos. Lin linao ¿dime? 21:26 26 abr 2024 (UTC)
Gracias a ambos. --angus (msjs) 21:27 26 abr 2024 (UTC)
@Angus, de momento la selección del idioma de la interfaz solamente está disponible para usuarios registrados, y el idioma por defecto en MediaWiki —donde apunta el enlace que proporcionas— es el inglés. Por tanto, los usuarios no logueados y quienes no tengan configurado ningún idioma accederán a la versión en inglés de ese enlace. -- Leoncastro (discusión) 21:28 26 abr 2024 (UTC)
Obtenido de «https://es.wikipedia.org/w/index.php?title=Wikipedia:Café/Portal/Archivo/Técnica/2024/04&oldid=160034785»