Ir al contenido

Diferencia entre revisiones de «Wikipedia:Café/Archivo/Técnica/Actual»

De Wikipedia, la enciclopedia libre
Explorar historial interactivamente
← Ir a diferencia anteriorIr a siguiente diferencia →
Contenido eliminado Contenido añadido
VisualWikitexto
Etiqueta: editor de código 2017
Etiqueta: editor de código 2017
Línea 357: Línea 357:
; Problemas conocidos:
; 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é [[Wikipedia:AutoWikiBrowser|AWB]]) para dejar solo en enlace, o directamente quitarlo, en pro de los los datos de Wikidata.
* {{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é [[Wikipedia:AutoWikiBrowser|AWB]]) para dejar solo en enlace, o directamente quitarlo, en pro de los los datos de Wikidata.
* Al usar <code>[[Módulo:Argumentos]].obtenerValorDeArgumentos()</code> junto con <code>[[Módulo:Argumentos]].obtenerTablaDeArgumentos()</code>, si la plantilla tiene un {{param|parámetro}} establecido, la tabla de argumentos (<code>argumentos{'captura'}</code>) entregará un valor de tipo <code>string</code> en lugar de <code>nil</code>, 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]].

--[[File:Flag_of_Chile.svg|20px|link=]] '''[[Usuario:Amitie 10g|Davod]]''' ([[Usuario_discusión:Amitie 10g|desquítense n_n]]) 21:12 14 nov 2020 (UTC)
--[[File:Flag_of_Chile.svg|20px|link=]] '''[[Usuario:Amitie 10g|Davod]]''' ([[Usuario_discusión:Amitie 10g|desquítense n_n]]) 21:12 14 nov 2020 (UTC)


Revisión del 01:35 15 nov 2020

Café: Técnica
Taza
Taza

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



Esta página es archivada automáticamente.

Parámetros del archivado:

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


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

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

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

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

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)[responder]
¿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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]
Pregunta: ¿Porqué ya no se usa Special:MergeHistory?--SRuizR ¡Pura vida! 17:43 11 ago 2020 (UTC)[responder]
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)[responder]
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)[responder]

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

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

Símbolo de grado centígrado en un solo carácter

Me acabo de percatar de que en la ayuda de edición que aparece debajo del cuadro de texto, que contiene atajos para la inserción de varias plantillas comunes y caracteres difíciles de introducir con un teclado normal, para el caso del grado centígrado o Celsius inserta el carácter Unicode «℃», el cual desconocía.

He indagado un poco sobre lo recomendable de este símbolo, en contraposición al símbolo de grado seguido de la ce mayúscula. En el manual de estilo no se hace referencia a este carácter. En la lista de símbolos no alfabetizables del DPD tampoco. Finalmente, en el propio artículo del grado Celsius se enlaza al estándar Unicode en el que no se recomienda el uso del símbolo: In normal use, it is better to represent degrees Celsius “°C” with a sequence of U+00B0 degree sign + U+0043 latin capital letter c, rather than U+2103 degree celsius. Una situación análoga se da con el símbolo para el grado Fahrenheit.

Si el símbolo no es recomendable, se debería plantear la eliminación (o modificación) de la lista de símbolos de la ayuda de edición de la Wikipedia, y quizá programar un bot para su reemplazo gradual (valga la redundancia). En cualquier caso se podría añadir una referencia en el manual de estilo. --Benjavalero (discusión) 08:12 27 oct 2020 (UTC)[responder]

Efectivamente no son usos recomendables, pues según la configuración del usuario pueden verse como cuadrados en lugar de los símbolos correspondientes. Creo que se habló no hace mucho en el Café sobre esto mismo o algo similar. Como sea no se hizo nada al respecto. Para modificar la herramienta que mencionas, bastaría con que un bibliotecario modificase los símbolos «℃» y «℉» respectivamente por las grafías «°C» y «°F», en las líneas 130 y 131 de la página MediaWiki:Edittools.javascript. Puedes plantearlo en el tablón. Además, su uso en artículos es bastante residual, pues solo me aparecen 108 páginas que los usen. Mi bot puede resolverlo fácilmente. Saludos. -- Leoncastro (discusión) 16:40 27 oct 2020 (UTC)[responder]
Hola Leoncastro. Gracias por indicarme cómo proceder. De momento voy a comentarlo en la discusión de MediaWiki:Edittools.javascript, aprovechando la sección de cuando se añadieron en 2013, y si no ya lo plantearé en el tablón. Mientras tanto ya he añadido el comentario en el manual de estilo. Por cierto, a mí me salen unas 2700 ocurrencias, me parece fantástico si quieres revisarlo con tu bot, yo por mi parte lo añadiré en breve a Replacer. Un saludo. --Benjavalero (discusión) 09:46 31 oct 2020 (UTC)[responder]
¿Tantas Benjavalero? Pero si ya he pasado el bot y no me localiza más que las propias páginas de grado Celsius buscando «℃» y grado Fahrenheit buscando «℉». -- Leoncastro (discusión) 13:40 31 oct 2020 (UTC)[responder]
Hola Leoncastro. En efecto, intentando el reemplazo con pywikibot solo aparece el resultado que dices. Sin embargo buscando de manera rápida a partir del último dump (20 de octubre) salen muchas más páginas, como Sol, Honduras, Atenas, Amoníaco, etc. que acabo de comprobar y en su revisión actual contienen el carácter «℃». Imagino que pywikibot y la búsqueda en la propia Wikipedia no se llevan del todo bien con los caracteres especiales. En fin, poco a poco lo iremos sustituyendo. --Benjavalero (discusión) 15:31 31 oct 2020 (UTC)[responder]

Tech News: 2020-45

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]
  • Elemento avanzado 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

  • Elemento recurrente 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

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

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

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

Memoria Lua

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

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

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

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

Wikidata weekly summary #441

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

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

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

Cita DANFS

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

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

{{Ficha de software}}: cambio a Lua

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

@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)[responder]
@Amitie 10g, por otro lado, deberías revisar el error que sale en Adobe Acrobat. -- Leoncastro (discusión) 22:45 14 nov 2020 (UTC)[responder]
@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)[responder]
Obtenido de «https://es.wikipedia.org/w/index.php?title=Wikipedia:Café/Archivo/Técnica/Actual&oldid=130934933»