Wikipedia:Café/Archivo/Técnica/Actual

De Wikipedia, la enciclopedia libre



Esta página es archivada automáticamente.

Parámetros del archivado:

Lugar: Wikipedia:Café/Portal/Archivo/Técnica/AAAA/MM
Días a mantener: 14
Avisar al archivar: Sí
Estrategia: Firma más reciente en la sección
Mantener caja de archivos: No


Necesitamos tu opinión - Plan anual del equipo de Producto y Tecnología de la Fundación Wikimedia[editar]

Este hilo no se archivará hasta el
30 de mayo de 2024. (info)

Hola a toda/os

Acabamos de publicar el borrador completo de los objetivos del equipo de producto y tecnología el año que viene. Les pedimos su opinión sobre cinco preguntas clave para ayudarnos a dar forma a las áreas de nuestro trabajo el año que viene. Les invitamos a compartir sus opiniones aquí en el Café, y yo ayudaré al personal y a los responsables de la Fundación a responder. Estas son nuestras preguntas:

  1. Ser voluntario en los proyectos Wikimedia debería ser gratificante. También creemos que la experiencia de la colaboración en línea debe ser una parte importante de lo que hace que los voluntarios sigan volviendo. ¿Qué hace falta para que los voluntarios encuentren gratificante la edición y colaboren mejor para crear contenidos fiables?
  2. La fiabilidad de nuestro contenido forma parte de la contribución única de Wikimedia al mundo, y es lo que hace que las personas sigan acudiendo a nuestra plataforma y utilizando nuestro contenido. ¿Qué podemos hacer para que los contenidos fiables crezcan más rápidamente, pero siempre dentro de los límites de calidad establecidos por las comunidades en cada proyecto?
  3. Para seguir siendo relevante y competir con otras grandes plataformas en línea, Wikimedia necesita que una nueva generación de usuarios se sienta conectada con nuestro contenido. ¿Cómo podemos hacer que nuestro contenido sea más fácil de descubrir y con el que puedan interactuar los lectores y donantes?
  4. En una época en la que proliferan los abusos en Internet, tenemos que asegurarnos de que nuestras comunidades, nuestra plataforma y nuestro sistema de servicios estén a salvo. También nos enfrentamos a obligaciones de cumplimiento en constante evolución, en las que los responsables políticos mundiales tratan de dar forma a la privacidad, la identidad y el intercambio de información en línea. ¿Qué mejoras en nuestras capacidades para combatir el abuso nos ayudarán a afrontar estos retos?
  5. MediaWiki, la plataforma de software y las interfaces que permiten que Wikipedia funcione, necesita apoyo continuo durante la próxima década para poder proporcionar creación, moderación, almacenamiento, descubrimiento y consumo de contenido abierto y multilingüe a escala. ¿Qué decisiones y mejoras de la plataforma podemos hacer este año para garantizar que MediaWiki sea sostenible?

Además de compartir sus opiniones sobre estas preguntas, volveré dentro de unas semanas para compartir el borrador de los resultados clave (pasos mensurables) de estos objetivos para que me envíen sus comentarios y sugerencias.

Muchas gracias, --Oscar . (WMF) (discusión) 19:45 14 mar 2024 (UTC)[responder]

Hola Oscar . (WMF), acá te dejo algunas ideas...
  • Acerca del número 3,
    • creo que ayudaría mucho tener un sitio que se enfoque al descubrimiento y la investigación. Las listas de lecturas son buenos avances, pero las herramientas deben ser capaces de añadir, por ejemplos, notas personalizadas para hacer referencias o releer información cuando la anotemos. En una analogía similar: usar el marcador/destacador cuando leíamos libros.
    • No sé si subirnos al carro de las LLM, pero generar resúmenes de artículos o secciones de los mismos.
    • Aunque no me gusta mucho la idea, debemos mantenernos desconectados de la agregación automática de contenidos/enlaces, ya que salen desde los servicios de la WMF, y por tanto, ya no se controlan por la comunidad (por ejemplo, incrustar videos desde YouTube o TikTok)
  • Acerca del número 4,
    • Desconozco si existe la capacidad, pero generar algoritmos o patrones de búsqueda de interacciones entre personas, detectando el potencial de mala fe o derechamente abusivos contra otro usuario.
  • Acerca del número 5,
    • Mediawiki es muy grande, en general. Quizás generando un curso en línea (MOOC?, Coursera?, YouTube) donde se enseñe a cómo programar o mantener código en Mediawiki sería de bastante ayuda para bajar un poco la barrera de entrada.
    • Sensibilizar el uso de Phabricator en las comunidades técnicas,
    • Invertir en generar comunidades técnicas que colaboren en la mantención del código como personas voluntarias... y a su vez, incrementar la visibilidad del trabajo voluntario en el código Mediawiki, quizás bajando la barrera de entrada al usar github (aunque claro está, no se hace por código cerrado + propiedad de MS)
Espero que te sea útil y que más editores puedan colaborar en estas preguntas :) Superzerocool (el buzón de msg) 12:09 15 abr 2024 (UTC)[responder]

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)[responder]

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)[responder]
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)[responder]
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)[responder]
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)[responder]
@Strakhov: el texto puede adaptarse. Un saludo.  νιяυм мυη∂ι @ ℓσg  14:35 16 mar 2024 (UTC)[responder]
@Leoncastro La documentaré o la eliminaré según sea el caso. Un saludo.  νιяυм мυη∂ι @ ℓσg  14:30 16 mar 2024 (UTC)[responder]
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)[responder]
@Virum Mundi, fase de pruebas iniciada. No creo que haga daño a nadie. -- Leoncastro (discusión) 16:25 16 mar 2024 (UTC)[responder]

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)[responder]

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)[responder]

"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)[responder]
@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)[responder]
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)[responder]
@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)[responder]
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)[responder]

┌─────────────────────────────┘
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)[responder]

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)[responder]

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)[responder]

  • 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)[responder]
✓ 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)[responder]

┌─────────────────────────────┘
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)[responder]

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)[responder]

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)[responder]

comentario Comentario un par de links se actualizaron a posteriori. strakhov (discusión) 17:20 2 abr 2024 (UTC)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]
@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)[responder]
@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)[responder]
Oferta 2×1. -- Leoncastro (discusión) 20:17 1 abr 2024 (UTC)[responder]
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)[responder]
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)[responder]

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)[responder]

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)[responder]

Noticias técnicas: 2024-14[editar]

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

Wikidata weekly summary #622[editar]

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)[responder]

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

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)[responder]

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)[responder]

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)[responder]

Wikidata weekly summary #623[editar]

Noticias técnicas: 2024-15[editar]

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

Wikidata weekly summary #622[editar]