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

< Wikipedia:Café‎ · Archivo‎ · Técnica(Redirigido desde «Wikipedia:Café/Portal/Archivo/Técnica/Actual»)
Café: Técnica
Taza
Icon tools.svg

En esta sección del Café de Wikipedia puedes plantear cuestiones técnicas de edición de páginas de Wikipedia.


Archivo del Café · Archivo temático del Café · Archivo de Técnica
Café
Noticias [+]
Políticas [+]
Técnica [+]
Propuestas [+]
Ayuda [+]
Miscelánea [+]
Ver todos

Temático

Atajo
WP:C/T




Fusión de historiales: copiar contenido de un lado a otroEditar

 Este hilo no se archivará. (info)
En seguimiento en Phabricator
Task T213618


Esto es algo en el que he puesto un poco más de atención en el último tiempo, sobre uno de los pasos para hacer una Fusión de historiales: ambos artículos deben ser iguales, cosa que no entiendo por que si, técnicamente, al fusionar, la versión más reciente quedará visible. De hecho, la documentación de MediaWiki no dice nada acerca de eso.

El problema viene que algunos bibliotecarios rechazan solicitudes de fusión de historiales porque las páginas difieren, en especial cuando se está editando activamente una página al momento de hacer la solicitud en el TAB.

Si bien no he leído (mucho) el código fuente de MediaWiki ni la documentación más esotérica, ni tampoco se cómo se utiliza la fusión de historiales, entiendo cómo funcionan varios aspectos técnicos, por lo que, para mi, ese paso me parece un tanto innecesario, o cuanto menos, que se exija. Se supone que los bibliotecarios deberían tener alguna noción básica de cómo funciona MediaWiki en ciertos aspectos, más allá de las instrucciones sobre procedimientos con sus botones. --  Davod (desquítense n_n) 03:58 11 ago 2020 (UTC)

Actualización: Ya vi cómo funciona la fusión de historiales, y sí, es un verdadero dolor de cabeza, entiendo a los biblios. En Phabricator hay una tarea que pide esas características desde enero de 2019, pero está estancada. Pienso que algún bibliotecario debería comentar ahí y exponer el "dolor" que representa hacer una tarea tan básica en sus funciones.

Otra cosa, en Wikipedia en inglés la hicieron fácil y optaron por dejar una redirección en lugar de fusionar historiales. ¿Qué opinan al respecto? --  Davod (desquítense n_n) 16:27 11 ago 2020 (UTC)

Depende del orden en que lo hagas. Sean X e Y dos artículos para fusionar en X, con contenido distinto. Tienes dos caminos. El largo para el bibliotecario es trasladar de X a Y, borrar, fusionar historiales y trasladar a X (4 pasos). El corto para el bibliotecario es que quien pide la fusión copie el contenido en Y y así solo haya que trasladar a X, borrar y fusionar historiales (3 pasos). Si no se hace esto, al trasladar desde Y a X, borrar y fusionar, quedará el contenido que no era (3 pasos, pero mal). La diferencia en 1 paso puede parecer mínima, pero la mayor cantidad de errores se produce en los traslados (si no recuerdo mal, una vez borré "Idioma español" y más encima perdí los historiales en una página mal nombrada :P , otro bibliotecario tuvo que hacer tejemanejes ingeniosos para salvarlo todo sin perder ni mezclar los historiales). Así que el pedido de fusión de contenido es para que la persona eche una mano en reducir la posibilidad de errores. Yo rechazo las fusiones de historiales cuando el artículo que queda no ha incorporado lo incorporable del otro. Saludos. Lin linao ¿dime? 04:13 11 ago 2020 (UTC)
¿Y no sería más simple hacer simplemente la fusión de historiales y ya, y revertir a la edición más reciente que se desea? Yo creo que en ese caso habría que pedir a los desarrolladores de MediaWiki una característica que permita establecer alguna revisión específica en el historial como la revisión más reciente. --  Davod (desquítense n_n) 04:34 11 ago 2020 (UTC)
Desconozco la historia de esta "directriz", pero me imagino que se habrá hecho como un paso adicional para asegurar que quien lo solicita ha acabado con los demás pasos de la fusión de artículos. Algo como una confirmación, porque lo más fácil es solicitar la fusión y que los admin ya se encarguen de hacer el trabajo de comprobarlo todo. Durante la fusión de artículos se supone que tienes que hace cierto trabajo - como mínimo comprobar que toda la información de uno está también en el otro, y si no tienes suerte también copiar secciones, editarlas, asegurarte de que encajen bien en el texto, quitar redundancias, repasar las referencias, etc. Si haces todo eso, el último paso del copy-paste es lo último que importa, créeme, de hecho te da una sensación de satisfacción, sabiendo que has terminado algo complicado, y los admin, a través de esta acción, también lo entienden. Y aunque no hayas tenido que copiar nada o se trata de un artículo corto, en este caso una sola acción tampoco sería pedir demasiado. De experiencia te digo que cuando la gente tiene que trabajar para conseguir algo, menos se le ocurre sencillamente solicitarlo y seguir adelante sin haber hecho nada ni comprobado nada (a veces hasta ni leyendo el artículo entero), dejando todo el trabajo a quien atiende la petición. Ya me imagino yo a ciertos usuarios repasando las listas de artículos a fusionar y bombardeando la página de fusión de historiales, que no les cuesta nada. En cuanto a que "algunos bibliotecarios rechazan solicitudes de fusión de historiales porque las páginas difieren", creo que es obvio, si existe dicha pauta (y hasta se subraya en negrita) entonces se sigue. Si fuera opcional, vale, pero si es parte de los pasos a seguir, obviamente se exige. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 05:41 11 ago 2020 (UTC)
No, no es más simple, porque quien "desea" que quede en una edición particular es el que pide la fusión. Entonces lo más simple es que él mismo lo deje como lo quiera y que el bibliotecario no tenga que preocuparse de ese detalle y pueda encarar la fusión como le parezca mejor. Además, se evitan malos entendidos y potenciales errores, y no cuesta tanto, ¿no? Saludos. --angus (msjs) 12:18 11 ago 2020 (UTC)
Hago fusiones todo el tiempo, y ese requisito me ahorra mucho tiempo: aunque técnicamente es indistinto el contenido inicial del artículo de destino, si un usuario confiable –los poco confiables no suelen hacer estos pedidos, aunque hay excepciones– hace una solicitud y veo que tiene el mismo número de bytes, lo hago sin revisar nada: 20-30 segundos de trabajo. Si hay una diferencia de bytes, tengo que ir a revisar ambos artículos, compararlos, ver cuál es la diferencia, cuál de los dos es la correcta, corregir todo y volver al TAB a hacer la fusión: 5 a 15 minutos de trabajo. O, dicho de otra forma, varios hilos del TAB que quedan sin responder. Saludos. --Marcelo   (Mensajes aquí) 15:06 11 ago 2020 (UTC)
El detalle aquí es que soy yo el que quiero hacer la fusión, y he seguido los pasos. En el caso particular de WarnerMedia Latin America → Turner Broadcasting System Latin America, ya propuse la fusión y lo había discutido en la página de discusión, por lo que ambos artículos son casi idénticos, casi, por que ambos están siendo editados en paralelo, y eso jamás se resolverá con tanta demora en atander a la solicitud de fusión de historiales que hice en el TAB (razón por la cual le pedí el favor a Usuario:Marcelo de atender la solicitud), y, como WarnerMedia Latin America es un copia/pega de Turner Broadcasting System Latin America, y, como no es una reestructuración tan compleja como lo es Turner Broadcasting System → WarnerMedia Entertainment y WarnerMedia News & Sports, no veo la necesidad de separar historiales. --  Davod (desquítense n_n) 02:15 12 ago 2020 (UTC)
  Pregunta: ¿Porqué ya no se usa Special:MergeHistory?--SRuizR   17:43 11 ago 2020 (UTC)
Por lo que he visto, la única herramienta disponible (al menos en una instalación vanilla de MediaWiki) es la extensión MergeHistory. --  Davod (desquítense n_n) 02:15 12 ago 2020 (UTC)
R, no la conocía o no la recordaba. La probé y solo funciona cuando los dos historiales no se superponen en el tiempo, la última edición del artículo fusionado tiene que ser más antigua que la primera del artículo que queda. Así que tiene utilidad para un número reducido de casos. Gracias y saludos. Lin linao ¿dime? 03:59 13 ago 2020 (UTC)

Para facilitar la labor de los sysop, he propuesto lo siguiente en Phabricator:

  • Listar el historial de ambas páginas a través de Especial:MergeHistory y permir seleccionar qué ediciones fusionar (todas por defecto), y permita seleccionar una revisión específica para que pase a ser el contenido visible una vez hecha la fusión (la última revisión de la página de destino por defecto).
  • Permitir fusionar historiales a través de Especial:MovePage, dejando la última revisión de la página de destino como la página visible por defecto, agregar la casilla de verificación "Fusionar historial" en adición a "Eliminar página de destino", junto con un enlace a Especial:MergeHistory para opciones de fusión avanzadas.

Invito cordialmente a los bibliotecarios a comentar en la tarea de Phabricator que enlacé. --  Davod (desquítense n_n) 04:41 13 ago 2020 (UTC)

"Invito cordialmente a los bibliotecarios a comentar en la tarea de Phabricator que enlacé": good luck with that. strakhov (discusión) 20:31 14 ago 2020 (UTC)

Memoria LuaEditar

En el artículo de Alemania aparecía un error al principio y al final de Lua: not enough memory. No se si es por un uso excesivo de plantillas de la Categoría:Wikipedia:Plantillas basadas en módulos Lua. No tengo ni idea. Le he quitado una del principio (distinguir) y ya ¿funciona?. No se, la verdad es que no tengo ni idea: intuitivo no es... Un saludo Kirchhoff (discusión) 05:13 5 nov 2020 (UTC)

Al momento de escribir este mensaje, en la versión de escritorio de Wikipedia no aparece ningún error. En cambio, en la versión de teléfonos móviles, se desaparece por completo la ficha de país junto con algunas referencias y el control de autoridades. Al iniciar una sesión de incógnito en mi navegador (con mi cuenta de Wikipedia cerrada), se desaparece, tanto en la vista móvil como en escritorio, el pie de foto que está debajo de la bandera de Alemania, en la ficha. Destaco que estos errores desaparecen cada ciertos minutos, para luego volver a aparecer, sin que nadie haga modificación alguna en el artículo. Benjamín Pérez Vera (discusión) 20:18 5 nov 2020 (UTC)

He probado el profiler en incógnito vs con mi cuenta y me da un consumo de memoria distinto en cada uno. Con mi cuenta se mantiene en 48.45MB mientras que en incógnito alcanza los 49.87MB (El límite es 50MB). No entiendo por qué se consume más memoria al no estar logueado pero eso resulta en que efectivamente el pie de foto de la bandera da error. Además la lista de transclusiones también cambia entre logeado e incógnito pasando de esta: 

<!-- Logueado
Transclusion expansion time report (%,ms,calls,template)
100.00% 4735.081      1 -total
 77.67% 3677.933      1 Plantilla:Ficha_de_país
 77.46% 3667.774      1 Plantilla:Ficha
 74.11% 3509.034      8 Plantilla:Propiedad
  8.14%  385.592      1 Plantilla:Control_de_autoridades
  7.61%  360.239      1 Plantilla:Listaref
  2.86%  135.481     47 Plantilla:Cita_web
  1.08%   51.070     13 Plantilla:Cita_libro
  0.93%   44.181      1 Plantilla:Estatus-HRC-país
  0.78%   36.724      1 Plantilla:Portal_asociado

A esta: 

<!-- Incognito
Transclusion expansion time report (%,ms,calls,template)
100.00% 4501.148      1 -total
 80.61% 3628.309      8 Plantilla:Propiedad
 76.66% 3450.523      1 Plantilla:Ficha_de_país
 76.43% 3440.037      1 Plantilla:Ficha
  7.80%  350.949      1 Plantilla:Listaref
  7.75%  348.755      1 Plantilla:Control_de_autoridades
  3.43%  154.192     47 Plantilla:Cita_web
  1.20%   53.953      1 Plantilla:Estatus-HRC-país
  0.90%   40.418      1 Plantilla:Portal_asociado
  0.81%   36.341      1 Plantilla:Icono_en_título

Traigo más preguntas que soluciones :) pero está claro que alguno de los módulos tiene una fuga de memoria porque tampoco es que el artículo tenga muchísimas plantillas. josecurioso ❯❯❯ Háblame! 22:11 5 nov 2020 (UTC)

@Josecurioso, ni es cuestión de «una fuga de memoria» ni tampoco es tan importante la diferencia entre logueado o de incógnito. El problema es el lenguaje y sus limitaciones. Una llamada en lenguaje de wikitexto consume cierta cantidad de memoria, y repetir la misma llamada multiplica el consumo tantas veces como se repita. Mientras tanto, la misma llamada en lenguaje Lua consume también cierta memoria, pero sus repeticiones no consumen prácticamente nada porque los resultados se guardan en caché. Aunque aparentemente el artículo no tenga muchas plantillas, tan solo la {{Ficha de país}}, además de usar unas pocas funciones costosas, al estar escrita en wikitexto carga hasta 21 veces los datos de Wikidata, que suponen 2 MB cada una de las veces. Resumiendo, esa ficha necesita una reescritura a lenguaje Lua. -- Leoncastro (discusión) 23:32 5 nov 2020 (UTC)

Wikidata weekly summary #441Editar

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Template:Cite Q on Wikipedia makes it easier to use Wikidata items as Wikipedia references.
  • Development
    • Continuing work with the WMF search team to automatically categorize WDQS queries to see how they can better be served
    • Query Builder work is continuing. Next step is making it possible to create a query with an arbitrary Property instead of the currently hard-coded post code.
    • Feedback round for the REST API is finishing this week and then we will review all the feedback and make changes to the spec accordingly.
    • Preparing to release 1.35 version of Wikibase docker image (phab:T264538)
    • Fixed Math extension to not require JS parser which caused issues creating new Statements for mathematical formulae (phab:T266673)
    • Made sure there is a meaningful edit summary when deleting a Lexeme (phab:T263435)

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.

Tech News: 2020-46Editar

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

Changes later this week

  • There is no new MediaWiki version this week.

Future changes

  • You can see reference previews. This shows a preview of the footnote when you hover over it. This has been a beta feature. It will move out of beta and be enabled by default. There will be an option not to use it. The developers are looking for small or medium-sized wikis to be the first ones. You can let them know if your wiki is interested. [1]
  • From November 16 the categories will not be sorted in order for a short time. This is because the developers are upgrading to a new version of the internationalisation library. They will use a script to fix the existing categories. This can take a few hours or a few days depending on how big the wiki is. You can read more. [2][3]

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

15:49 9 nov 2020 (UTC)

Imágenes subidas a Commons no vuelcan en WikipediaEditar

Por si a alguien le está ocurriendo que una vez subida una imagen a Commons, no vuelca al editarla en un artículo de Wikipedia, se ha abierto consulta alli. Soluciones son bienvenidas, desconozco si se ha reportado el bug.--Xabier (discusión) 17:14 10 nov 2020 (UTC)

Cita DANFSEditar

Buenas. Notifico que la {{cita DANFS}} no funciona correctamente.--Malvinero10 (discusión) 20:54 10 nov 2020 (UTC)

   Ahora debería. -- Leoncastro (discusión) 21:19 10 nov 2020 (UTC)
Ahora si. Perfecto, Leoncastro, gracias.--Malvinero10 (discusión) 00:29 11 nov 2020 (UTC)

{{Ficha de software}}: cambio a LuaEditar

Estimados, anuncio la actualización dea plantilla {{Ficha de software}} a Lua. Loa cambios en la ficha incyen:

  • Que la captura (imagen (P18)) tenga un ancho máximo estándar fijado en ese módulo.
  • Si la altura de la captura es mayor a algún valor (ej. 300px), la imagen se debe recortar usando la propiedad CSS object-fit (véase esta guía).
  • Si existe una captura, el logotipo (P154) debe ser más pequeño (ej. 100px).
  • Historial de versiones importado desde Wikidata.
Nota: El historial de versiones se fcomo enlace en lugar de como referencia, ya que en el caso de un historial de versiones extenso implicaría llamar a la plantilla {{Cita web}} demasiadas vecelo que podría causar problemas de rendimiento y análisis.
Problemas conocidos
  •   Hecho La sección enlaces se muestra erroneamen debido a que dichos enlaces se suelen formatear como enlace wiki en lugar de una URL. Se deben editar los artículos (mediante bot o herramienta automatizada; probaré AWB) para dejar solo en enlace, o directamente quitarlo, en pro de los los datos de Wikidata.
  • Al usar Módulo:Argumentos.obtenerValorDeArgumentos() junto con Módulo:Argumentos.obtenerTablaDeArgumentos(), si la plantilla tiene un |parámetro= establecido, la tabla de argumentos (argumentos{'captura'}) entregará un valor de tipo string en lugar de nil, incluso si el parámetro establecido en la plantilla no contiene ningún valor. La solución es, o quitar los parámetros sin valor de las plantillas, o bien manejarlo en Módulo:Argumentos.

--  Davod (desquítense n_n) 21:12 14 nov 2020 (UTC)

@Amitie 10g, revisa a ver si este arreglo es suficiente para resolver el problema con la sección de enlaces. -- Leoncastro (discusión) 22:43 14 nov 2020 (UTC)
@Amitie 10g, por otro lado, deberías revisar el error que sale en Adobe Acrobat. -- Leoncastro (discusión) 22:45 14 nov 2020 (UTC)
@Leoncastro, ya he resuelto el error que me indicas. Cualquier error, favor reportar aquí. --  Davod (desquítense n_n) 00:57 15 nov 2020 (UTC)
@Amitie 10g, sobre esta nueva anotación. Primero, por favor, no edites mensajes a los que ya te hemos respondido, mejor agrega los nuevos comentarios a continuación. De otro modo se nos puede pasar desapercibido el leer la nueva aportación, y por tanto responderla, porque pensamos que ya te hemos leído y respondido con anterioridad. Segundo, lo que describes no es un problema sino una funcionalidad. La lectura resulta en nulo si no existe el parámetro, y resulta en una cadena vacía si se ha dejado el parámetro intencionalmente en blanco. Hay funciones donde interesa conocer precisamente esa diferencia. Al codificar puedes detectar el primer caso como if not captura, el segundo como if captura == '', o en caso contrario como if captura and captura ~= ''. No tiene mayor problema. -- Leoncastro (discusión) 01:59 15 nov 2020 (UTC)

Es importante que en el resumen de la modificación en los artículos que llevan la ficha de OS se explique el motivo del cambio. Ya que de no ser así, pueden haber reversiones, como ya ha ocurrido. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 23:34 15 nov 2020 (UTC)

Estadísticas sobre ancho de los monitores usados por los lectores de WPEditar

Hola,

¿Existen estadistícas o algún tipo de información sobre el ancho en pixels de los monitores usados por los lectores de Wikipedia?. ¿En América del Sur?.

Antiguamente los monitores tenían un ancho de 640px, pero desde ya hace varios años solo veo en el comercio monitores de 1098px o más anchos aún.

Dejando de lado los smartphones, me interesa saber que parte de los lectores WP puede ver completamente en su pantalla una imagen de 550px, 800px o 1000px.

Saludos, --Juan Villalobos (discusión) 10:26 16 nov 2020 (UTC)

@Juan Villalobos:. Yo no las he visto en una pasada rápida, aunque aquí tienes antiguas y las nuevas. Si es por tomar otros servidores, por ejemplo esta de España: Resolucion: 1366x768 (17%), 360x640 (17%), 1920x1080 (9%) y así hasta mas de 7000 resoluciones de pantalla distintas; creo que esas estadisticas se pueden sacar de muchos servidores y no creo que cambie mucho en los servidores de Wikimedia. Aquí o aquí tambien hay cosas de fuera de nuestros servidores.
Y si lo que planteas es una encuesta yo uso, aparte de dispositivos móviles, un portatil con 1280x768 cuando estoy fuera de casa, un 21' de 1600x900 cuando me usan el ordenador en las clases online (lo que tiene la conciliación y el confinamiento), 1920x1080 normalmente en casa, y esa o superior cuando estoy en el trabajo... Incluso con una persona no se si eso es facil de saber. Si no es mucho preguntar ¿por qué quieres saberlo? El diseño adaptable, responsivo, etc supongo que es más propio de mediawiki que de aquí; si comentas la razón igual alguien puede orientar en que partes de ese proyecto se trata ese tema.--Kirchhoff (discusión) 11:53 16 nov 2020 (UTC)
@Kirchhoff: Me sorprende la variedad de pantallas y también que tantas sean muy pequeñas (smartphones). De screenresolution.org he escogido de las primeras 20 pantallas más comunes el porcentage de las pantallas con más de 1000px y obtengo la suma de 60,63%.
La primera causa de la pregunta es que existe en WP una recomendación de incluir las imágenes sin ancho fijo para que el rendering utilice el ancho más apropiado de acuerdo al monitor o dispositivo que reciba la página. Normalmente es una recomendación difícil de seguir en las páginas sobre ríos. La segunda es que hay una plantilla {{Cuencas hidrográficas de Chile}} con ImageMap bastante ancha porque de otra manera no se distinguen las cuencas pequeñas.
Tengo la duda cual es la mejor opción: 1) seguir la recomendación 2) crear varios ImageMaps menos anchos?
Yo creo que con más de un 60% de monitores >1000px se puede considerar que el uso de una imagen muy ancha no es muy apropiado (por razones de estética) pero puede ser visto y utilizado sin problemas por la mayoría de los lectores. El uso de ImageMap con una imagen ancha está bastante bien resuelto en mi smartphone.
El caso de la recomendación es más general y probablemente más complicado. Un mapa es ideal para describir el trayecto de un río, pero el lector debe por lo menos alcanzar a leer el nombre del río, lo que en algunos casos exige imágenes grandes.
Suma sumarum, creo que como lo he hecho está bien. Saludos, --Juan Villalobos (discusión) 16:49 16 nov 2020 (UTC)
@Juan Villalobos, lo mejor es el diseño adaptable, el cual ya se puede generar gracias a los TemplateStyles (por ejemplo en el diseño de la portada). Aunque no sé cómo se puede compaginar esa modernidad con ImageMap; habría que analizarlo. -- Leoncastro (discusión) 17:08 16 nov 2020 (UTC) PD: la imagen de {{Cuencas hidrográficas de Chile}} no sale completa en móviles, ni siquiera en horizontal (al menos en iPhone 6-X, ni Samsung S9), ni tampoco en tabletas con pantallas de 1280 de resolución. -- Leoncastro (discusión) 17:14 16 nov 2020 (UTC)
Una interesante herramienta para un avezado editor de WP. Actualmente en los smartphones ya aparece la imagen aislada, sin texto a su lado, lo que ya es bueno.
No se si se pueda hacer, pero me imagino tres soluciones al problema de imágenes "grandes".
Una, aplicable solo a las imágenes muy anchas, pero chatas, sería girar la imagen en 90°. En el caso de la plantilla dejaría el eje vertical para el eje N-S. No conozco la herramienta, pero me imagino que es posible portar el ImageMap.
La otra solución sería aplicar una lupa, como lo hace p. ej. David Rumsey Historical Map Collection. Tiene la ventaja de que el lector puede ver en un thumbnail la posición de la sección que esta viendo ampliada. ImageMap?.
La tercera es { { panorama|Helsinki z00.jpg|1800px|Panorama de Helsinki|25%|right|alt=Panorama de Helsinki... } } . Esta no permite la inclusión de un ImageMap.
Saludos, --Juan Villalobos (discusión) 11:14 17 nov 2020 (UTC)
@Juan Villalobos, sobre girar noventa grados, véase .ejemplo { transform: rotate(90deg); };[4][5][6] sobre la lupa, quizás Map draw puede servir como alternativa (en lugar de usar una imagen de fondo se pueden generar áreas y marcas sobre un mapa actual); y sobre {{panorama}}, pues queda una imagen estática con el mismo problema original. De entre todas, me gusta más la segunda, porque es la más completa y la que mejor resultado ofrece al lector (aunque sin duda también es la más compleja). -- Leoncastro (discusión) 15:53 17 nov 2020 (UTC)

OpenStreetMap, la fuente de Map Draw, es fabuloso, pero requiere acostumbrase a usarlo. En el zoom https://www.openstreetmap.org/#map=11/-35.8980/-71.6405 aparece casi toda la cuenca del río Maule, pero no aparece el nombre de río alguno, solo el lago Colbún y 9 ciudades en una región que en realidad tiene muchos poblados. Para mostrar barrios o ciudades es bueno porque aparecen calles y nombres. Pero cuando son zonas campestres, los ríos y poblados no aparecen. Además, a veces sus servidores tienen sobrecarga de trabajo y no contestan rápidamente. Los límites digitalizados de las cuencas están disponibles y pueden ser almacenados en WP, Commons u OSM.

La posibilidad de escalar con CSS no es la apropiada porque aumenta las dimensiones de la imagen pero disminuye la resolución. Interesante es solo cuando se ven más detalles. --Juan Villalobos (discusión) 13:46 18 nov 2020 (UTC)

Repito Juan Villalobos —porque parece que no ha quedado claro— «quizás Map draw puede servir como alternativa (en lugar de usar una imagen de fondo se pueden generar áreas y marcas sobre un mapa actual)». Se trataría en todo caso de generar las áreas y las anotaciones que lleva ese mapa estático, pero mostrados sobre la base de un mapa dinámico. De ahí mi aclaración de que «sin duda también es la [opción] más compleja». Esta capa generada se almacena generalmente en Commons. Observa por ejemplo cómo se visualiza este mapa que muestra el río Boeza —tomando los datos desde c:Data:Boeza river.map— y su cuenca de drenaje —tomando los datos desde c:Data:Boeza drainage basin.map— (si pulsas sobre el río muestra su nombre y longitud, y la cuenta nombre y superficie). Además de puntos, líneas, o polígonos sobre el mapa, se pueden generar regiones (como los barrios de Mueva York) y múltiples combinaciones. Más ejemplos en Plantilla:Map draw/uso/ejemplos. Estoy seguro de que Galopax puede guiarte mejor con este tipo de mapas. -- Leoncastro (discusión) 16:27 18 nov 2020 (UTC)
Por alusiones, voy a tratar de aportar mi punto de vista a este interesante debate.
En primer lugar, Juan Villalobos, y por evitar rodeos, si se trata de trabajar con información geográfica —cuencas hidrográficas, ríos, y demás—, hay que hacerse a la idea del uso de Sistemas de Información Geográfica, una visión o perspectiva que no se contempla en entornos Wikimedia. La vía sería trabajar con un GIS, por ejemplo QGIS, en entornos externos y, una vez generada la información de interés, exportarla como GeoJSON y tratarla según mw:Help:Map Data. Este es, a día de hoy, y por lo que yo conozco, el único formato admitido en Commons y, a su través, en Wikipedia. La única forma de integrar información geográfica digital en modo vectorial.
Efectivamente, la base cartográfica en que se integra esta información es OpenStreetMap y, también efectivamente, hay zonas en las que no existe información, casi de ningún tipo. Nombres, ríos, calles, más aún en zonas campestres. Ante ello, solo hay una solución: densificar el mapa, aportar, integrar la información que falta, que sea de interés. Y ¿cómo?
Pues con dos vías. La primera, pidiendo ayuda a alguien de la comunidad OSM y ver si puede hacer algo. La segunda, haciéndolo uno mismo pues, no se olvide, OpenStreetMap es la Wikipedia de la información geográfica, en la que todo el mundo puede participar. Probablemente, iniciando la primera vía, se acabe llegando a la segunda (https://wiki.openstreetmap.org/wiki/ES:Guía de principiantes).
Todo lo demás, los métodos que hasta hoy se vienen usando en Wikipedia, es trabajar con imágenes ráster, con imagen de mapa de bits, que resumiríamos como «fotos». Esto, como ya señalas en el inicio, genera otra serie de problemas que, en lo que tratamos, se han de solucionar usando siempre dimensiones proporcionales, %, no dimensiones absolutas, 600px por ejemplo, pues, con ese tipo de dimensión, se saldrán, no se adaptarán al marco, a la pantalla. Un problema asociado, como creo pasa en la plantilla {{panorama}}, es que las propias plantillas ya se configuren en unidades absolutas, o integren las imágenes en esa dimensión, con lo que el problema es más complejo, pues habría que modificar la propia plantilla. Al menos que permitan la dimensión proporcional, que muchas no lo admiten.
Un método, que podríamos llamar intermedio, es el uso de ImageMaps, Mapa de imagen, algo que se inventó, en su momento, en el inicio del entorno HTML, y, que teniendo su funcionalidad en determinadas aplicaciones, ya no es funcional cuando se trata de imágenes complejas, como en el gran trabajo que has realizado en {{Cuencas hidrográficas de Chile}} pero que, al final, tiene todos los inconvenientes de las imágenes ráster, estáticas, como ya has detectado.
En resumen, creo la orientación que te ofrece Leoncastro puede ser la más adecuada, sin complicarte mucho la vida, aprendiendo GIS y temas relacionados, que por cierto, aconsejo en general, más si se quiere trabajar con mapas. En todo caso, el uso de la plantilla Map draw, quizás combinada con mw:Help:Map Data, proporciona unos entornos en los que se pueden integrar iconos que llamen a imágenes, mapas de detalle que equivaldrían, de algún modo, a la lupa, como lo hace p. ej. David Rumsey Historical Map Collection, una referencia que pones, y que es de otra división en cosas de mapas.
Finalmente, puedes tomar alguna idea, además de en Plantilla:Map draw/uso/ejemplos, en Usuario:Galopax/Ayuda:Mapas interactivos o Usuario:Galopax/Pintando mapas. Sin desesperar, ánimo y suerte :-) --GALoPaX (discusión) 11:18 19 nov 2020 (UTC)
Tienes razón, por eso hemos utilizado Map Draw en Anillo verde ciclista y QGIS para crear la colección de 94 mapas hidrográficos y hemos creado en OSM las "relation" que reúne los trazos de cada río para conectarlos a Wikidata por medio del identificador de relación OpenStreetMap y de esa manera aparecen en la ventana de "control de autoridades" bajo el nombre "Lugares: OSM ...". Hasta ahí está muy bien. Pero la cantidad y calidad de detalles en los mapas raster es como para ponerlos bajo una lupa. Debemos creer en el Viejito Pascuero!. Saludos, --Juan Villalobos (discusión) 15:03 19 nov 2020 (UTC)
Bueno, me sorprendes muy gratamente, Juan Villalobos, pues veo que eres un experimentado cartógrafo, con, por ejemplo, la exhaustiva descripción que haces en los mapas hidrográficos de Commons. De hecho, quizás te pida ayuda con algo que llevo un tiempo tratando de hacer, vinculado con OSM y "relation".
En todo caso, y al hilo de esta conversación, pienso en lo último que decía, el usar marcas o iconos en coordenadas específicas, estratégicas, que llamen a imágenes, como la foto que se llama en uno de los puntos de Anillo verde ciclista, pero siendo esas imágenes mapas raster, resultando mapas de detalle, con información que OSM probablemente nunca tendrá, incluso porque no sea acorde a la política de OSM, y a la escala adecuada; ... recortes de ortofotos comentadas... la lupa, entre que llega el Viejito Pascuero, o los Reyes Magos ;-)
De momento, a seguir con todo un poco. Saludos, --GALoPaX (discusión) 17:47 19 nov 2020 (UTC)

Update to ICU Unicode libraryEditar

Starting on November 16, we will migrate the servers running the MediaWiki application servers to a new release of the ICU Unicode library (w:International Components for Unicode) (from version 57 to 63).

This unblocks some future work on upgrading the servers to a new Operating System release and will also allow the use of improved internationalisation in the future (as wikis will then be able to use features introduced by the new ICU release such as new collation definitions, and allows us to use a more recent version of Unicode in MediaWiki).

This migration will cause some unavoidable temporary user-visible impact: The sorting of some category pages will be distorted – all pages which have been updated with the new software version will use the new sorting while untouched pages still use the old sorting. As such, we need to run a maintenance script to update the sorting for old entries.

The distortions may last from a few hours (on medium-sized wikis), up to a day (on the largest wikis), and a few days on English Wikipedia. The start-time will depend upon when the migration script reaches each wiki.

This affects 149 wikis (including eight out of the ten biggest Wikipedias). The detailed list and the task for the technical implementation is at T264991.

Thank you.

Trizek (WMF) 14:53 16 nov 2020 (UTC)

Tech News: 2020-47Editar

Estas son las noticias técnicas más recientes de la comunidad técnica de Wikimedia. Informa sobre estos cambios a otros usuarios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios recientes

  • El contenido de las categorías se organiza utilizando una librería. El día 16 de noviembre y durante un breve periodo de tiempo el contenido de las categorías aparecerá desordenado para la mayoría de los idiomas mientras los desarrolladores proceden a actualizar la librería ICU a una nueva versión. Tras la actualización, se utilizará un script para que los listados vuelvan a mostrarse debidamente ordenados. Ello puede tardar bien unas horas o incluso días dependiendo del tamaño de la wiki. Puedes leer más sobre ello. [7][8]

Cambios de esta semana

  • Las fusiones de páginas e historiales solían fallar cuando se realizaban en espacios de nombres que no admitían redirecciones. Esto ha sido arreglado. [9]
  •   La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 17 noviembre. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 18 noviembre, y en las restantes a partir del 19 noviembre (calendario).

Cambios futuros

Las Noticias Técnicas son preparadas por los redactores de Noticias Técnicas y publicadas con un bot • Colabora • traduce • obtén ayuda • comenta • suscríbete o cancela tu suscripción.

15:36 16 nov 2020 (UTC)

Wikidata weekly summary #442Editar

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • ALEC (A List of Everything Cool) is a tool to explore biodiversity content in Wikidata.
  • Other Noteworthy Stuff
    • Join the upcoming #1Lib1Ref Wikipedia campaign from January 15th to February 5th 2021 and improve Wikidata items by adding references to statements.
  • Development
    • Added "Random lexeme" link under dedicated section for lexicographical data in the Wikidata sidebar (phab:T205525). Thanks to Matěj Suchánek!
    • Working on language/spelling variant selector bug on Special:NewItem and Special:NewLexeme that makes it difficult to continue creating Items or Lexemes (phab:T266638)
    • Work on the Query Builder continues. We're focusing on making it possible to query for all Items with a specific Property but any value next.
    • Went over all the feedback we have received for the REST API specification draft. Overall the feedback is positive and really useful. So we will move ahead after thinking more about the remaining points that were raised.
    • Working on making changes to descriptions show up in the RecentChanges feed and watchlists on Wikipedia and co as well even if they are not explicitly used (phab:T191831)
    • Fixed a problem adding statements with Properties of datatype mathematical formula (phab:T266496)
    • Kicked off our new effort to implement a predictable release cycle and release infrastructure for Wikibase suite by creating a prototype build workflow (phab:T267553) and prototype test workflow (phab:T267554)

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.

Nueva funcionalidad: Lista de seguimiento temporalEditar

¡Hola a todos! El equipo de Tecnología Comunitaria lanzará una nueva funcionalidad llamada Lista de seguimiento temporal. Con esta funcionalidad, opcionalmente puede vigilar una página durante un período de tiempo temporal. Esta funcionalidad fue desarrollada en respuesta al deseo número 7 de la Tecnología Comunitaria 2019 Wishlist Encuesta. Para saber cuándo se habilitará la funcionalidad en su wiki, consulte el programa de lanzamiento en Meta-wiki. Para probar la funcionalidad antes de la implementación, puede visitar mediawiki.org o testwiki. Una vez que la funcionalidad esté habilitada en su wiki, los invitamos a todos a compartir sus comentarios en la página de discusión del proyecto. Para más información, consulte la página de documentación. ¡Gracias, y esperamos escuchar sus comentarios! --IFried (WMF) (discusión) 18:41 18 nov 2020 (UTC)

Quien quiera probar, también está activa en Commons y Wikidata desde ayer. -- Leoncastro (discusión) 20:46 18 nov 2020 (UTC)

Múltiples "deshechos"Editar

Hau! Quería preguntar si existe alguna posibilidad de realizar la acción de deshacer varias ediciones a la vez (lo mismo que en el caso de revertir). 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 19:57 22 nov 2020 (UTC)

@Virum Mundi: Ayuda:Cómo revertir una edición--SRuizR   20:05 22 nov 2020 (UTC)
Gracias SRuizR, pero lo dicho - revertir varios artículos a la vez lo sabemos todos, quería saber si existe lo mismo para deshacer cuando no se trata de vandalismos (pudiendo añadir el motivo), y tengo buen motivo para preguntarlo porque creo que si no existe, es lo que fomenta el uso incorrecto de la herramienta de revertir que se hace por muchos usuarios que cuentan con dicho permiso. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 20:10 22 nov 2020 (UTC)
@Virum Mundi: lo que te enlacé no tiene nada que ver con la herramienta revertir. Usando el método que puse se puede poner resumen de edición.--SRuizR   20:12 22 nov 2020 (UTC)
Ah, vale, solo había leído el título, ya - es el método que solíamos usar antes, quería saber puntualmente si existe la opción para la acción de deshacer (sin tener que entrar en el artículo, aunque ahora que lo pienso solo supone un paso más). Lo que ocurre (y eso ya es un tema para un nuevo hilo) es que últimamente "pillo" a muchos usuarios que para ahorrarse estas "fases intermedias" usan la herramienta de revertir aunque no se trata ni de vandalismos ni de ediciones arbitrarias (y se podría, y hasta se debería, explicar el por qué de la reversión). En la gran mayoría de estos casos me he dado cuenta de que se trata de más de una edición del mismo usuario que se ha revertido, de ahí la pregunta. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 20:26 22 nov 2020 (UTC)

Tech News: 2020-48Editar

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

  • Timestamps in Special:Log are now links. They go to Special:Log for only that entry. This is how timestamps work on for example the history page. [10]

Changes later this week

  • There is no new MediaWiki version this week.

Future changes

  •   The Wikimedia Cloud VPS hosts technical projects for the Wikimedia movement. Developers need to claim projects they use. This is because old and unused projects are removed once a year. Unclaimed projects can be shut down from 1 December. Unclaimed projects can be deleted from 1 January. [11]

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

17:18 23 nov 2020 (UTC)

Wikidata weekly summary #443Editar

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • EntityShape.js is a script that allows you to check an Item against an EntitySchema. On the Item page, it will display various information about the Item, like the properties that should be present on the Item.
  • Development
    • Query Builder: We're making it possible to switch between querying for specific values (e.g. all Items with a specific post code) or any value (all Items with a post code statement regardless of which one it is)
    • Correcting the behaviour of what automatically happens on Wikidata when a page is moved on Wikipedia and co to an excluded namespace with the "suppress redirect" option (phab:T261275)
    • Making language fallback indicators not show up for language variant fallbacks in a few more places (phab:T267502)
    • Adding html language attributes for statements linking to Forms and Senses (phab:T267023)
    • Working on language and lexical category fields turning red on unfocus even though no changes are made after a change in ooui (phab:T266936)
    • Finished building the 1.35 versions of the Wikibase base and bundle docker images and published to dockerhub (phab:T264538)

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.

Obtenido de «https://es.wikipedia.org/w/index.php?title=Wikipedia:Café/Archivo/Técnica/Actual&oldid=131156293»