Wikipedia

Wikipedia:Café/Portal/Archivo/Técnica/2020/11

< Wikipedia:Café · Portal · Archivo · Técnica
Último comentario: hace 4 años por Josecurioso en el tema Problemas en la ficha de entidad subnacional
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.


Tech News: 2020-45

editar

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

  • Si tu navegador usa un protocolo TLS muy antiguo ya no podrás seguir leyendo páginas de ningún proyecto de la Fundación Wikimedia. Permitir protocolos TLS muy antiguos supone un problema de seguridad para todos en tanto que puede provocar ataques vía downgrade. A partir del 29 de octubre de 2020 los usuarios cuyos navegadores utilicen versiones de TLS antiguas no podrán conectarse a los servidores de Wikimedia. Se proporciona una lista de recomendaciones. Todos los sistemas operativos y navegadores modernos pueden conectarse sin problemas. [1]
  •   Se ha creado una nueva categoría de seguimiento: Páginas con argumentos formatnum no numéricos. En ella se listarán todas las páginas que usan la parser function {{formatnum}} con caracteres inválidos (no numéricos), como por ejemplo: {{formatnum:TECHNEWS}}. Nótese que {{formatnum:123,456}} tampoco es un formato válido. Tal y como se establece en la documentación, el argumento debe darse sin formato para que pueda ser traducido correctamente. Esta categoría de seguimiento ayudará a identificar los problemas anteriormente descritos. El nombre de esta nueva categoría puede traducirse en translatewiki. [2]

Cambios de esta semana

  •   La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 3 noviembre. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 4 noviembre, y en las restantes a partir del 5 noviembre (calendario).
  • Los administradores (bibliotecarios) y los stewards podrán acceder a una nueva página especial (Special:CreateLocalAccount) para crear una cuenta local para una cuenta global existente. Esto puede resultar de utilidad cuando la creación de cuentas se encuentra bloqueada bien por la existencia de bloqueos o filtros de ediciones. [3]
  • La herramienta para responder a comentarios se ofrecerá como característica en fase beta y opcional para casi todas las Wikipedias el miércoles 4 de noviembre. Ello no incluirá las Wikipedias en inglés, ruso y alemán, así como otras Wikipedias más pequeñas en las que existen circunstancias especiales. Puedes leer la página de ayuda y la de resolución de problemas para mayor información. [4]

Cambios futuros

  • Se ha reabierto una discusión acerca de usar el signo menos en Unicode (− U+2212) cuando el resultado de {{formatnum}} sea negativo. [5]
  • Las direcciones IP de los usuarios no registrados no serán visibles para todos los usuarios en un futuro. Se les asignará un alias en su lugar. Se sopesa crear un nuevo permiso de usuario o una función opcional para que los usuarios que se dedican a patrullar y combatir el vandalismo puedan acceder a esa información. Se establecerán criterios para regular dicho acceso, y se crearán nuevas herramientas para ayudar a gestionar y combatir el vandalismo. Esta propuesta está todavía en un estado incipiente y los desarrolladores todavía están en período de recopilar información de las comunidades antes de sugerir cualquier tipo de solución.

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.

16:08 2 nov 2020 (UTC)

Wikidata weekly summary #440

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión
 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: Hasley (RfP scheduled to end after 2 November 2020 17:23 UTC)
  • Events
    • Past: Wikidata & Wikibase office hour, October 27 (notes)
    • Upcoming: Next Linked Data for Libraries LD4 Wikidata Affinity Group call: Arthur Smith and Daniel Mietchen discussing author items in Wikidata and the Author Disambiguator Tool, 3 November. Agenda
    • Upcoming: Online Wikidata editathon in Swedish #37, November 8
    • Upcoming: live SPARQL queries on Twitch and in French by Vigneron, November 3 at 18:00 CET
This is 32 hours of video covering 85 individual presentations in 7 languages.
1266 "unique viewers" have watched some portion on YouTubeSince the conference began last Monday.
  • Tool of the week
    • reCH is a Wikidata anti-vandalism tool that is used to review edits and patrol new changes.
  • Development
    • Fixing the issue of `content was: ""` (empty string) when deleting Lexemes (phab:T263435)
    • Final steps for deployment of JSON dumps for Lexeme (phab:T264883)
    • Working on fixing an issue with adding statements with datatype mathematical formula (phab:T266673)
    • The Query Builder can now generate its first very simple query and show the result. You can follow along as we develop it at the demo system.

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.

Ficha noble

editar
Último comentario: hace 4 años3 comentarios2 usuarios en la discusión

Hola, quería saber si es posible añadir otro parámetro a la Plantilla:Ficha noble para poder incluir amantes con quienes tuvieron descendencia. Ahora solamente hay dos opciones, cónyuge y consorte. Vemos, por ejemplo, que en artículo de Alfonso XI de Castilla, no figura en la ficha la célebre amante con quien tuvo muchos hijos. Gracias y saludos, --Maragm (discusión) 08:34 3 nov 2020 (UTC)

En lugar de perder esfuerzos en tratar de ampliar dicha ficha, debería usarse la {{Ficha de persona}}. -- Leoncastro (discusión) 14:20 3 nov 2020 (UTC)
Gracias. Yo pensaba que la ficha persona era la que importaba los datos de wikidata automáticamente. La usaré de ahora en adelante. --Maragm (discusión) 14:37 3 nov 2020 (UTC)

Memoria Lua

editar
Último comentario: hace 4 años4 comentarios4 usuarios en la discusión

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 #441

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión
 
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-46

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.

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. [6]
  • 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. [7][8]

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 Wikipedia

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión

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 DANFS

editar
Último comentario: hace 4 años3 comentarios2 usuarios en la discusión

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 Lua

editar
Último comentario: hace 4 años6 comentarios3 usuarios en la discusión

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)

Update to ICU Unicode library

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión

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-47

editar

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. [9][10]

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. [11]
  •   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 #442

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión
 
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 temporal

editar
Último comentario: hace 4 años2 comentarios2 usuarios en la discusión

¡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)

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

editar
Último comentario: hace 4 años11 comentarios4 usuarios en la discusión

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); };[12][13][14] 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)

Múltiples "deshechos"

editar
Último comentario: hace 4 años5 comentarios2 usuarios en la discusión

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-48

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

  • 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. [15]

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. [16]

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 #443

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión
 
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.

Plantilla de premios de música

editar
Último comentario: hace 4 años9 comentarios2 usuarios en la discusión

Hola a tod@s,

tengo una duda y no sé como arreglarla, ya que he probado varias cosas.

Existe la Plantilla:Premios de música por año que cuando se incrusta va muy bien, ya que aparece un calendario con la consecución anual anterior y posterior. Sin embargo, tiene un poco de lío con la categorización, pues al incrustar dicha plantilla, se añade automáticamente la categoría: Anexos del año en cuestión.

Por ejemplo, en la Categoría:Anexos:Premios de música de 2020 aparece categorizada como Categoría:Anexos:2020 y no es necesario, ya que ya está categorizada en Categoría:Anexos:Premios de 2020. ¿Pueden ayudarme? Creo que en la de cine sucede lo mismo.

¡Gracias! Wifrey (discusión) 12:36 28 nov 2020 (UTC)

:Para solucionar eso habría que implementar un parámetro en {{Categoría por año}} que permita anular esa categorización 'general'. Lo he implementado como prueba en {{Categoría por año/zona de pruebas}} y lo puedes utilizar con {{Premios de música por año/zona de pruebas}}. No lo he puesto en la versión principal de la plantilla porque es muy usada y tampoco quiero cargarme nada importante, prefiero que otro le eche un vistazo. josecurioso ❯❯❯ Háblame! 14:39 28 nov 2020 (UTC)

También cabe la posibilidad de que ese sea el comportamiento esperado y realmente esto no sea un problema. josecurioso ❯❯❯ Háblame! 14:40 28 nov 2020 (UTC)
Tacho lo anterior, la solución es modificar {{Categoría por fecha (núcleo)}} para que cuando reciba 'Anexos:Premios de música' solo categorice en 'Música en XXXX' pero insisto, no sé si es un error o el comportamiento esperado. josecurioso ❯❯❯ Háblame! 14:50 28 nov 2020 (UTC)
¡Gracias por contestar Josecurioso (disc. · contr. · bloq.)!
Pero sigo sin entender que debo hacer, yo no sé arreglar eso del núcleo... :S Si me lo explicas para Dummies como yo, a lo mejor lo voy pillando. Yo lo único que veo es que la Categoría:Anexos:2020 no debería aparecer en Categoría:Anexos:Premios de música de 2020.
¡Saludos! Wifrey (discusión) 10:07 29 nov 2020 (UTC)
Lo siento Wifrey, que con las prisas ayer me expliqué fatal :). Ya lo arreglé ayer, de hecho purgué la Categoría:Anexos:Premios de música de 2020 y ya no aparece categorizada en Categoría:Anexos:2020. Así que debería estar arreglado. Un saludo josecurioso ❯❯❯ Háblame! 11:03 29 nov 2020 (UTC)
Sí, está solucionado. ¡Muchas gracias! Wifrey (discusión) 21:21 29 nov 2020 (UTC)
Sin embargo, me sucede la necesidad imperiosa de entender, ¿cómo puede ser que sólo poniendo < ! - - - - > estos símbolos se quite la Categoría:Anexos:2020 en Categoría:Anexos:Premios de música de 2020?, me parece magia. Wifrey (discusión) 21:26 29 nov 2020 (UTC)
¡Muchas denadas @Wifrey!, para satisfacer tu curiosidad en wikitexto (y por lo general en cualquier documento HTML/XML) cualquier cosa que pongas entre los símbolos <!-- --> se interpreta como un comentario al código. Esto hace que se "ignore" cuando se interpreta la página web o, en este caso, la plantilla. Es muy útil para explicar que hace una línea sin afectar al funcionamiento del programa y en este caso me sirve para "eliminar" esa categoría sin eliminarla del código. Un saludo, josecurioso ❯❯❯ Háblame! 22:17 29 nov 2020 (UTC)

Parámetro «Estudio»

editar
Último comentario: hace 4 años5 comentarios2 usuarios en la discusión

Buenas tardes. Espero que este sea el lugar apropiado para mi consulta. Siempre tengo esa duda. Hace ya 15 meses dejé un mensaje en la discusión de la plantilla de ficha de sencillo, en el que proponía si podía agregarse un nuevo «parámetro» en dicha ficha, así como en la de canción y en la de álbum. Nadie respondió. Curioso, porque en agosto de este año otro usuario dejó un mensaje después de mí y a las dos horas le llegó una respuesta. Bueno, no es la primera vez que sucede esto. Volviendo al tema, ¿sería posible agregar un nuevo parámetro llamado «Estudio» (lugar donde se grabó X álbum/sencillo/canción) en esas fichas, después del parámetro de «Grabación» (fecha en la que se grabó X álbum/sencillo/canción), tal como sale en la Wikipedia en inglés, con su correspondiente descripción? Intenté hacerlo yo, pero al editar se me armó un lío y mejor lo dejé, no quise estropear las fichas. ¿Será posible? Gracias a quien responda esta solicitud. MadonnaFan 21:00 29 nov 2020 (UTC)

@MadonnaFan, resolviendo tu curiosidad, y dado que yo fui quien respondió al mensaje siguiente omitiendo el tuyo, lo hice así esperando que hubiese mayor participación en tu propuesta, pues presentabas dos alternativas: crear un nuevo parámetro o ingresar los datos en otro existente. El mensaje siguiente trataba de un error en la plantilla, lo cual no necesita mayor participación para ser resuelto. Atendiendo a tu consulta, sí, es posible crear el nuevo parámetro |estudio=; aunque no sé qué tan necesario es porque tú mismo proponías reutilizar el parámetro |grabación=. Un saludo. -- Leoncastro (discusión) 15:09 30 nov 2020 (UTC)
Creo que me expliqué mal. O yo entendí mal tu respuesta, Leoncastro. En el mensaje que dejé en la discusión de la plantilla propuse si se podía crear ese parámetro de Estudio, y luego pregunté (esperando que alguien respondiera a esa pregunta y me sacara la duda, cosa que no pasó) si con el parámetro |Grabación era suficiente con incluir la fecha y el lugar. Nunca presenté dos propuestas. Siempre fue la misma: poder incluir el nuevo parámetro de Estudio. En la descripción de la plantilla se indica que |Grabación se utiliza solo para detallar la fecha en la que se grabó un álbum o una canción/sencillo (de tal año a tal año, de tal mes de X año a tal mes de otro año), pero he visto en muchos artículos de música (incluso en los que yo he traducido/colaborado en estos años) que aquí en la Wikipedia en español se agrega además el lugar (nombre del estudio de grabación y ciudad), cuando el parámetro no indica eso. Muchos álbumes/sencillos incluyen en sus liner notes el lugar donde se grabó tal material. De ahí mi propuesta, tras ver en la Wikipedia en inglés que existe ese parámetro. No solo eso, también he visto otro llamado |Venue=, usado por lo general en los artículos relacionados con álbumes en vivo. De eso trata mi mensaje. No hay dos propuestas, solo una. Lo que quiero saber es si se puede hacer y, ahora que me lo has confirmado, si tú u otro usuario podría hacerlo, ya que en mi caso se me ha dificultado cuando lo intenté yo mismo. Por mi parte me gustaría la creación de ese nuevo parámetro, en lugar de incluir en otro existente, en este caso en el de |Grabación=. Y no creo que requiera más participación, si nadie se tomó la molestia de acercarse a la discusión de esa plantilla en estos quince meses, dudo que ahora alguien quiera opinar algo. De todas formas, tampoco es que pido que se cambie una política o se modifique toda la plantilla. Sería opcional usarlo o no, como casi todos los otros parámetros de la ficha. Saludos. MadonnaFan 16:04 30 nov 2020 (UTC)
Evidentemente es una cuestión que no va a requerir una votación. @MadonnaFan, a lo que me refiero es que, aunque no lo hubieras propuesto formalmente, sí presentabas dos formas diferentes de ingresar ese valor en las fichas: una, mediante un nuevo parámetro; y otra, a través del parámetro existente de la grabación. Porque la duda está en que el estudio es normalmente el lugar de grabación. Y si ya se está poniendo el lugar en el parámetro de grabación, usar el nuevo parámetro de estudio será redundante. Yo no lo he cambiado, no para esperar un consenso favorable, o una alta participación, sino esperando una mejor explicación o más ideas, así como la confirmación de cómo se usa el parámetro existente. Porque de esa participación que esperaba, también podrían salir ideas como reemplazar |grabación= por |fecha grabación= y |lugar grabación= —que será más genérico y versátil que «estudio» y «venue»—, o cualquier otro argumento de los interesados en esas plantillas. Si tampoco hubo interés... Lo que no voy a hacer es cambiar algo que no sé exactamente cómo está funcionando y cómo se pretende hacer que funcione tras el cambio. La modificación en la plantilla es técnicamente sencilla: basta con agregar, por ejemplo, |etiqueta8 = Estudio |datos8 = {{{estudio|}}} después de la línea de la grabación (datos7), e incrementar los números de todas las líneas sucesivas (tanto etiquetaX, como datosX, como seccionX). El problema está en cómo se realizará el cambio de uso. -- Leoncastro (discusión) 21:34 30 nov 2020 (UTC)
Bueno, gracias por responder. MadonnaFan 22:28 30 nov 2020 (UTC)

Wikidata weekly summary #444

editar
Último comentario: hace 4 años1 comentario1 usuario en la discusión
 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming: Next Linked Data for Libraries LD4 Wikidata Affinity Group call: We will have several speakers joining us to discuss their projects in lightning talks, 1 December. Agenda
    • Upcoming: WMF search platform team office hour, Wednesday, December 2nd, 2020. 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET. Etherpad, Google Meet. You can come and chat about the Wikidata & Commons Query Service.
    • Online edition of the Wikimedia Coolest Tool Award ceremony, on Friday, December 11th at 17:00 UTC.
    • Upcoming: Online Wikidata meetup in Swedish #41, December 6
  • Tool of the week
    • osm2kg is a tool to facilitate matching Wikidata entries to OSM nodes.
  • Development
    • Development on the Query Builder is continuing. You can follow along at https://query-builder-test.toolforge.org
    • Fixed an issue where language fallback indicators were still shown when falling back from a variant of the language (phab:T267502)
    • Fixed an issue on Lexeme pages where language and lexical category fields turn red on unfocus even though no changes were made (phab:T266936)
    • Working on improving what happens to sitelinks when an article is moved to a unsupported namespace (phab:T261275))
    • Investigating a significant increase in skipped Item IDs (phab:T268625)
    • Addressing the feedback for the draft of the REST API spec

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-49

editar

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 de esta semana

  •   La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 1 diciembre. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 2 diciembre, y en las restantes a partir del 3 diciembre (calendario).

Cambios futuros

  • La aplicación de Wikipedia para iOS mostrará más sobre el historial del artículo a los lectores, permitiendo ver cómo ha cambiado el artículo con el tiempo. Esto es una función experimental que solo se activará para algunos usuarios de la aplicación a modo de prueba. [17][18]
  •   Las Wiki Replicas son copias de las bases de datos de Wikimedia sin información privada que pueden usarse para hacer consultas SQL a través de varias plataformas como Quarry o PAWS entre otras. Al objeto de hacer el servicio más estable no se van a permitir en lo sucesivo poder hacer consultas con parámetros JOIN a otras bases de datos, debiendo conectarse directamente a cada una de las respectivas bases que queramos consultar. Este cambio surtirá efecto en el mes de febrero de 2021. Si crees que este cambio te afecta y necesitas ayuda puedes pedir ayuda en Phabricator o en Wikitech. [19]

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

17:44 30 nov 2020 (UTC)

Problemas en la ficha de entidad subnacional

editar
Último comentario: hace 4 años2 comentarios2 usuarios en la discusión

Hola. La ficha de entidad subnacional, que solamente pueden editar bibliotecarios, tiene un comportamiento inesperado cuando, usando el autorellenado enlazado a Wikidata, aborda nuevas reformas administrativas. El 1 de enero de este año Noruega ha reducido el número de fylke (condado, mejor que provincia, del ámbito latino, que en noruego es provinz) y también el número y delimitación de muchos municipios. En Wikidata han realizado un buen trabajo y han fechado esos cambios duplicando las pertenencias a entidades administrativas. Pero la ficha tiene problemas en escoger el campo más reciente, asi como lo tiene también al rellenar el campo superficie en que llegaa acumular hasta 10 datos diferentes. Ver casi cualquier municipio noruego, sin completar manualmente la ficha: p.e., Farsund. Ese compartamiento extraño también lo hace al cargar los mapas con las divisiones municipales antiguas. ¿Alguien puede echarle un vistazo? Cuidaos mucho y mil gracias. Urdangaray (discusión) 19:34 30 nov 2020 (UTC)

Hola Urdangaray, estuve mirando el tema de las superficies y creo que está solucionado en la zona de pruebas de la plantilla. También dejé un mensaje en la página de discusión para que algún bibliotecario los revise y acepte/rechace. Sobre el resto de problemas que mencionas no he tenido tiempo de mirarlos. Un saludo, josecurioso ❯❯❯ Háblame! 23:10 30 nov 2020 (UTC)
Obtenido de «https://es.wiki.x.io/w/index.php?title=Wikipedia:Café/Portal/Archivo/Técnica/2020/11&oldid=131737071»