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
Línea 489: Línea 489:
El problema es que lo reconoce como bucle de pantalla ya que, por ejemplo, si coloco la plantilla en la página principal en efecto la primera pestaña incluye esta página, y así será para todas. Pero en realidad no es así ya que cuando se incluye el código de la pestañas enteramente en la página principal, por ejemplo, no aparece un enlace sino una letra en negrita sin enlace, como suele pasar siempre cuando se inserta en una página un enlace a la misma. Por eso no entiendo para qué sirve eso del bucle ni cómo solucionar este problema sin tener que introducir el código de pestañas en cada página. Programáticamente es como si me quitasen las subrutinas diciéndome que no puede ser. '''[[Usuario:Virum Mundi|<span style="color: darkred; font-size: 15px">𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦</span>]]&nbsp; &nbsp;[[Usuario_discusión:Virum_Mundi|<span style="color: #666666">🗣</span>]]''' 06:45 6 oct 2020 (UTC)
El problema es que lo reconoce como bucle de pantalla ya que, por ejemplo, si coloco la plantilla en la página principal en efecto la primera pestaña incluye esta página, y así será para todas. Pero en realidad no es así ya que cuando se incluye el código de la pestañas enteramente en la página principal, por ejemplo, no aparece un enlace sino una letra en negrita sin enlace, como suele pasar siempre cuando se inserta en una página un enlace a la misma. Por eso no entiendo para qué sirve eso del bucle ni cómo solucionar este problema sin tener que introducir el código de pestañas en cada página. Programáticamente es como si me quitasen las subrutinas diciéndome que no puede ser. '''[[Usuario:Virum Mundi|<span style="color: darkred; font-size: 15px">𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦</span>]]&nbsp; &nbsp;[[Usuario_discusión:Virum_Mundi|<span style="color: #666666">🗣</span>]]''' 06:45 6 oct 2020 (UTC)
: Retiro mi consulta. Aunque aún no entiendo el por qué, en el caso de las pestañas también se trataría de adaptación del diseño, así que ya lo hago manualmente. '''[[Usuario:Virum Mundi|<span style="color: darkred; font-size: 15px">𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦</span>]]&nbsp; &nbsp;[[Usuario_discusión:Virum_Mundi|<span style="color: #666666">🗣</span>]]''' 07:33 6 oct 2020 (UTC)
: Retiro mi consulta. Aunque aún no entiendo el por qué, en el caso de las pestañas también se trataría de adaptación del diseño, así que ya lo hago manualmente. '''[[Usuario:Virum Mundi|<span style="color: darkred; font-size: 15px">𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦</span>]]&nbsp; &nbsp;[[Usuario_discusión:Virum_Mundi|<span style="color: #666666">🗣</span>]]''' 07:33 6 oct 2020 (UTC)

== Archivos multimedia en es.wikipedia o acceso indirecto a Commons desde es.wikipedia ==

Pido perdón por adelantado si esta consulta corresponde a otra sección, espero no haberme equivocado, me ha parecido una duda técnica fundamentalmente... Querría saber si sería posible activar el almacenamiento de archivos audiovisuales en es.wikipedia como tienen las enciclopedias en otros idiomas (la inglesa seguro, creo que alguna otra también) o si existe alguna herramienta que desde es.wikipedia permita colocarlos en Commons sin que el usuario tenga que interactuar con Commons (aunque lo haga la herramienta). Aporto algunos ficheros de este tipo para la enciclopedia, pero no voy a volver a Commons y en en.wikipedia ya no me permiten colocar ficheros para pasarlos de ahí a Commons para poderlos usar en la enciclopedia española, así que tengo la duda entre si hay posibilidad (en principio, técnica) de colocarlos bien directamente en es.wikipedia o en Commons desde es.wikipedia o si me olvido de contribuir este material a la enciclopedia. Gracias a todo el que me pueda aclarar si es posible o no...--[[Usuario:Rowanwindwhistler|Rowanwindwhistler]] ([[Usuario Discusión:Rowanwindwhistler|discusión]]) 11:41 6 oct 2020 (UTC)

Revisión del 11:41 6 oct 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]

Artículos creados sobre redirecciones

Con el hilo Wikipedia:Café/Archivo/Propuestas/Actual#Páginas nuevas creadas con el taller, recuerdo que también se suelen hacer artículos en espacios que son redirecciones. Se pone el contenido borrando la redirección y «listo el pollo», artículo nuevo que no aparece en Especial:PáginasNuevas. Yo mismo he creado artículos de este modo, aunque garantizo su calidad (al menos no son para el borrado rápido, ja). ¿Hay algo que controle esto?--Malvinero10 (discusión) 15:47 20 sep 2020 (UTC)[responder]

@Malvinero10, para eso se pueden filtrar los cambios recientes por la etiqueta «Redirección eliminada» (así). Similar a lo que propongo hacer con los traslados del taller. -- Leoncastro (discusión) 14:15 21 sep 2020 (UTC)[responder]
Muy bien.--Malvinero10 (discusión) 17:13 21 sep 2020 (UTC)[responder]

Wikidata weekly summary #434

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming: Online Wikidata Introduction Workshop (German) (September 29)
    • Upcoming: live SPARQL queries on Twitch and in French by Vigneron, September 21 at 18:00 CEST
    • Upcoming: Next Linked Data for Libraries LD4 Wikidata Affinity Group call: A starting point for newer institutions to think through what is involved in coordinating a Wikidata project, including shared infrastructure, training, and documentation, 22 September. Agenda
    • Upcoming video: Wikipedia Weekly Network - LIVE Wikidata editing #21 WikiDojo: Facebook, YouTube, September 25
  • Tool of the week
    • copy-qid is a user script by Abbe98 that allows you to copy the Qid with one click.
  • Other Noteworthy Stuff
  • Development
    • WQS now supports mwapi service request for Wikibooks (phab:T261125)
    • The language codes lij-mc, ja-Hira, ja-Kana, ja-Hrkt, ja-Hani, ojp, ojp-Hira and ojp-Hani" have been added for use in monolingual text property values (phab:T254968, phab:T195816)
    • The language codes de-1901, eo-hsistemo and eo-xsistemo, ja-hira, ja-kana and ja-hrkt have been added for Lexemes (phab:T262330,phab:T257422, phab:T250559)
    • P1438 has been converted from string to external ID datatype (phab:T262198)
    • Worked on fixing an input issue with invisible characters (phab:T261071)
    • Investigating what work would be needed to get the new termbox that's available on mobile to also work on desktop
    • Fixing several issues with Special:Undelete (phab:T261747)
    • Fixing an error message being shown twice (phab:T260869)
    • Starting the coding work on the Query Builder
    • Continuing to write a draft for a REST API specification
    • Finishing the remaining work needed to get the improved quality scoring for Items deployed to ORES
    • Continuing work on WikibaseManifest: Determined the essential metadata that will be included in the WikibaseManifest file, added some new features (mostly MediaWiki metadata) to the Manifest that were requested by the OpenRefine team (phab:T262805 and phab:T262804) and set up a test system that will soon be ready for tool builders to use for testing the integration of their tools with WikibaseManifest


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

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

  • Existe una nueva etiqueta (tag) para las ediciones revertidas. Estas etiquetas aparecen en los Cambios Recientes o en el historial de los artículos. Las etiquetas se añaden a las ediciones que han sido desechas, revertidas o revertidas manualmente a una versión antigua de la página. [1][2]

Cambios de esta semana

  • El número de veces que puedes hacer algunas acciones en las wikis poseen un límite. Estos límites pueden ser el número de ediciones por minuto o el número de usuarios a quienes puedes enviarles un correo electrónico. Algunos usuarios no son afectados por los límites debido a sus permisos de usuarios. A futuro, podrán ver el límite incluso si no se ven afectados por él. [3]
  • Elemento recurrente La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 22 septiembre. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 23 septiembre, y en las restantes a partir del 24 septiembre (calendario).

Noticias técnicas preparadas por escritores de Noticias Tec y publicadas por un bot • Contribuya • Traduzca • Obtenga ayuda • Denos su opinión • Suscríbase o cancele su suscripción.

21:26 21 sep 2020 (UTC)

Cambios en la señalización de palabras en el editor visual

En seguimiento en Phabricator

Desde siempre cuando se modifica el formato de una palabra, frase o párrafo, las palabras señaladas quedan marcadas por el cursor. Lo mismo que ocurre en Word o en cualquier editor de toda la vida. En los últimos días ha cambiado el comportamiento del editor visual y, mientras que en el editor de código sigue siendo lo mismo, en el visual ahora si cambio el formato (digamos que pongo una palabra en negritas), el cursor cambia de posición (con un comportamiento "errático") y se hace muy difícil editar el artículo. ¿Alguien sabe si se trata de un bug o si es un cambio a conciencia? Gracias. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 06:34 23 sep 2020 (UTC)[responder]

Parece más un error. He tratado de dar con unos pasos para reproducirlo en todas las ocasiones, y es bastante curioso. Para empezar, solo logro reproducir el problema cuando el cambio de formato se hace con atajos de teclado, no con los botones del menú. Usando atajos de teclado, lo reproduzco cuando selecciono una palabra o conjunto de palabras sin seleccionar ningún espacio alrededor. Esto es relevante porque al hacer doble clic sobre una palabra se selecciona junto con el espacio posterior, y en este caso no reproduzco el problema. En cuanto al comportamiento errático, el que yo reproduzco siempre (en los casos que acabo de describir) es que el cursor se posiciona al comienzo de la línea. Espero que estas pruebas sirvan para acotar y resolver el problema. --Benjavalero (discusión) 07:28 23 sep 2020 (UTC)[responder]
Hola, creo que está reportado en este ticket en Phabricator. Superzerocool (el buzón de msg) 15:32 23 sep 2020 (UTC)[responder]
Buenas, sorry, acabo de ver vuestros comentarios. Benjavalero: Sí, yo también he seguido las mismas pautas más o menos, lo de las teclas de atajo y los espacios. O sea, que si la elección del texto incluye un espacio al principio, al final o ambos, todo bien, si no - es cuando se produce el bug, es decir que el texto pierde su marcado y el cursor se posiciona al principio del párrafo (ahora parece que siempre, al principio a veces desaparecía del todo y dándole a la tecla de flecha hacia abajo aprecía directamente por debajo de la palabra marcada). Como dices cuando se elige una palabra por doble clic, se selecciona junto con el espacio posterior, pero si la palabra es seguida por un signo de puntuación, sí que se marca la palabra sola y se produce el error. Ahora bien, en mi caso, y es una costumbre de toda la vida, muchas veces para subrayar o quirtar el subrayado de ciertas palabras, maro la sección entera o la frase entera y le doy dos vece a la tecla del atajo. El problema es que aunque se elija una combinación de palabras con un espacio en uno de los extremos, el mismo queda fuera del texto marcado después de pulsar la tecla de atajo la primera vez. En fin, un embrollo que espero se solucione cuanto antes. Superzerocool: Gracias, aunque este ticket solo contiene parte del problema. De todos modos al parecer este bug que para mí supone un problema no lo es para muchos, ya que se ha comentado bien poco. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 11:11 25 sep 2020 (UTC)[responder]

Cambio de aspecto en Wikipedia

Hola. Hace poco comentábamos sobre un espacio en blanco en la Wikipedia en francés. Ahora hay más información sobre los cambios que vendrán y aquí podemos ver ejemplos. Saludos. Lin linao ¿dime? 04:06 24 sep 2020 (UTC)[responder]

Yo estoy usando la nueva versión de Vector (configurada en las opciones globales), y la interfaz me parece mucho más cómoda, principalmente a la hora de editar, salvo porque el gran margen del contenido, razón por la cual edité la hija de estilos CSS global para que el contenido de despliegue al ancho completo. Es un buen y necesario cambio. -- Davod (desquítense n_n) 06:36 24 sep 2020 (UTC)[responder]
Nice! 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 11:12 25 sep 2020 (UTC)[responder]

Problema con ° y º

Hola. Tenemos el artículo Destacamento de Montaña n.º 8 Tucapel y no se puede llegar directamente al escribir Destacamento de Montaña n.° 8 Tucapel, hay que crear una redirección. ¿Quiere decir que para muchos no es posible llegar a cientos o miles de artículos a menos que alguien haga redirecciones? ¿Es adecuado que estemos usando º o se trata de un carácter especial que casi nadie tiene en sus teclados? Lo pregunto desde el punto de vista técnico y de la usabilidad para los usuarios. Saludos. Lin linao ¿dime? 18:53 25 sep 2020 (UTC)[responder]

Nótese que según la tipografía utilizada pueden mostrarse casi idénticos, en el primer título se usa una o volada (para ordinales) y en el segundo un círculo volado (para grados). En el momento en que se usan caracteres distintos los títulos de las páginas pasan a ser distintos. Lo mismo ocurre por ejemplo con las mayúsculas o con los acentos. Por tanto en estos casos es necesario crear redirecciones. En cuanto al carácter usado en el título de la página, es correcto el uso de la o volada tal y como se indica en el Manual de estilo. Finalmente desconozco la dificultad de introducir la o volada con el teclado, hasta donde yo sé en los teclados en español (los que incluyen la ñ) incluyen también una tecla para esto, arriba a la izquierda. De hecho, el carácter que normalmente es difícil de introducir es el del grado. ¿Qué distribución de teclado usas? --Benjavalero (discusión) 06:08 28 sep 2020 (UTC)[responder]
Gracias, Benjavalero uso un teclado QWERTY que se llama "Español (latinoamericano)", supongo que es el corriente para la mayoría, ¿o tal vez no?. Hago ° con la tecla que está a la izquierda del 1 (la primera tecla de la segunda fila, debajo de Escape y sobre Tabular), da | en condiciones normales y ° al presionar al mismo tiempo la flecha que también permite hacer las mayúsculas. ¿Qué teclado usas tú? Saludos. Lin linao ¿dime? 01:43 29 sep 2020 (UTC)[responder]
Hola, Lin linao. Pues tienes toda la razón. He podido acceder a un equipo con Windows donde he configurado el teclado español latinoamericano y efectivamente la tecla que indicas inserta el símbolo de grado, y no hay manera directa de incluir la o volada. Hay distribuciones personalizadas que cubren esta carencia (v. [4]) pero no es la solución ideal. Con el teclado configurado con español de España pasa al contrario, hay una tecla para insertar la o y la a voladas, pero no para el grado. Curiosamente parece que en Mac no se da este problema porque se usa la misma distribución de teclado. Sinceramente me temo que no es algo con fácil solución. Hay muchísimos títulos que no se pueden escribir con un teclado normal (p. ej. Novak Đoković) pero que son accesibles con varias redirecciones. Y el caso que comentas parece que cae en este casuística. Un saludo. --Benjavalero (discusión) 06:20 29 sep 2020 (UTC)[responder]

Categoría:Pages with non-numeric formatnum arguments

Hay una categoría automática de, creo, reciente aparición y nombre sin traducir (Categoría:Pages with non-numeric formatnum arguments) que es posible que se haya descontrolado. No es algo muy técnico, pero si alguien supiera a razón de qué aparece (en varios artículos en ella incluidos a primera vista no parece haber problema con datos no-numéricos en plantillas como "formatnum" pero a saber... ¿quizás fichas?) y si es necesaria, traducir su nombre y crearla. Un saludo. strakhov (discusión) 11:43 26 sep 2020 (UTC)[responder]

Probando, me di cuenta que debería funcionar cuando un parámetro que debería tener un número contiene otra cosa que no es un número. Eso está bien, pero hay un problema: Esta categoría cuenta a los espacios entre números (que se recomienda en el manual de estilo) como un carácter no numérico, y categoriza. Véase, por ejemplo, 2.º distrito congresional de Colorado. Si remplazamos el número «721 615» por «721615» la categoría se elimina del artículo (basta con solo previsualizar la página). Esto no solo pasa en las fichas normales (las que aparecen siempre a la derecha), sino que también ocurre en otros cuadros como en Albertville.
La categoría podría estar bastante bien, pero es claro que debería contemplar los espacios duros.--Santiago142857 01:45 27 sep 2020 (UTC)[responder]
La categoría ayudaría al mantenimiento, aunque no es enciclopedica. Pero lo malo es que es "peor" lo que hace: aquí se arregló con cambiar los valores de formatnum, pero en mi taller sigue estando y el único código que he dejado es {{Especificaciones de aeronave |techo vuelo = 12000 }}. No se que tipo de valor espera la plantilla, pero supongo que ese, solo un número. Bcoto (discusión) 07:11 27 sep 2020 (UTC)[responder]
Definitivamente está mal: en esa plantilla se espera un número y hace bien la conversión y demás, pero si se pone un número lo incluye en la categoría. Si se pone detrás la m de metros ya no lo hace, pero la plantilla ya no funciona bien porqué el formato no es el esperado. Bcoto (discusión) 07:18 27 sep 2020 (UTC)[responder]
Del 24 de septiembre en la WP:en la explican. Pero a mí no me gusta y creo que funciona mal si una plantilla llama a otra, pero bueno.... Bcoto (discusión) 21:14 27 sep 2020 (UTC)[responder]

┌─────────────────────────────┘
 Cada vez que se usa {{formatnum:NÚMERO}} debería ser para formatear un número interno obtenido de una operación o cálculo; ese NÚMERO debe ser única y exclusivamente un número sin formato (según su documentación). Sin embargo en multitud de plantillas se está usando para formatear un parámetro de entrada que se espera que contenga un número, aunque usualmente viene acompañado de un texto, como puede ser su unidad de medida. Esto engaña al sistema y hace que el formateo resulte erróneo en determinadas ocasiones. Entiendo que han tenido que crear esta categoría de seguimiento para poder buscar una solución al problema.
Sea como sea, parece evidente que se trata de una categoría de mantenimiento, por lo que debería renombrarse con el prefijo «Categoría:Wikipedia:», y preferentemente con un título en español, categorizada a su vez como {{Categoría automática|MediaWiki:...}}, igual que el resto de categorías de seguimiento del sistema; aunque por lo visto todavía no le han asignado una entrada en el espacio «MediaWiki:», por lo que de momento tan solo se puede hacer un parche para ocultarla. -- Leoncastro (discusión) 18:17 28 sep 2020 (UTC)[responder]

Lua, plantilla o Wikidata?

Hola,

en Río Maullín aparece un error en la {{Ficha de cuerpo de agua}}. Conoce alguien la solución?. --Juan Villalobos (discusión) 20:08 26 sep 2020 (UTC)[responder]

Tiene pinta de que el error ocurre porque Módulo:Convertir no sabe cómo manejar la unidad "cubic metre per second". En muchos otros casos el dato del caudal se especifica directamente en la plantilla del artículo pero en este se trae de Wikidata especificando que es una magnitud. Eso hace que Wikidata intente utilizar el otro módulo para mostrarla correctamente. La solución sería añadir soporte para esa unidad en Módulo:Convertir. Voy a intentarlo yo mismo a ver si me sale pero es la primera vez que lo hago. Un saludo, josecurioso ❯❯❯ Háblame! 21:03 26 sep 2020 (UTC)[responder]
Arreglado, he hecho el cambio en Convertir y una prueba en Convertir/tests y parece que funciona. josecurioso ❯❯❯ Háblame! 21:20 26 sep 2020 (UTC)[responder]
Gracias!!!. --Juan Villalobos (discusión) 22:10 26 sep 2020 (UTC)[responder]

Puesta en superíndice de los enlaces interlingüísticos

Buenos días a todos,

He notado esta mañana esta modificación por parte de Sabbut, que tiene un impacto a nivel global en wp:es.

No ha sido discutido en ninguna parte y me sorprende que se tome este tipo de iniciativa sin consultarlo con la comunidad.

Se lo he preguntado a Sabbut, y he aquí sur respuesta.

No quiero armar ningún conflicto, no hay problema y puede que en el fondo tenga toda la razón, pero sí creo que se debería hablar con la comunidad antes de hacer una modificación con semejante impacto.

Un saludo, --Daehan (discusión) 12:53 27 sep 2020 (UTC)[responder]

Según la propia documentación de la plantilla {{Enlace interlingüístico}}:
Según el Manual de estilo se desaconseja introducir enlaces a otras wikipedias dentro del cuerpo del artículo. Si no existe un artículo en la Wikipedia en español, es mejor que quede a la vista con un enlace en rojo, que incluir un enlace a otra Wikipedia.
Por tanto, no debería incluirse dicha plantilla en los artículos. Agregado a esto, los argumentos de Sabbut me parecen correctos, y el cambio me parece menor en todo caso. -- Leoncastro (discusión) 14:27 27 sep 2020 (UTC)[responder]

Wikidata weekly summary #435

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Other Noteworthy Stuff
    • The Wikidata development team is seeking to evaluate and improve the process of collecting and reacting to bug reports and feature requests. You can give feedback about your experience using this anonymous form until September 30th or add feedback publically to Wikidata talk:Contact the development team/Process review 2020.
    • Nominate your favorite tools for the Coolest Tool Award 2020 before October 14th.
    • Wikidata Walkabout is a new site that lets you browse and drill down through different "classes" of data on Wikidata: wikidatawalkabout.org
    • Como is a new Android app, that uses Wikidata lexemes and senses to create a word-guessing game. It let's players create new senses and tests them on other players to finally save them in Wikidata. The app is developed as part of a BA thesis, to determine if this concept is useful to create more lexicographical data, and testers would be very welcome.
  • Development
    • A long-standing bug has been fixed (T217144) where Items and Lexemes created via OAuth would not be added to the user’s watchlist even if the user had the Vigilar páginas creadas setting enabled. (The Vigilar páginas modificadas setting was probably likewise ineffective, but this was not tested specifically.) Affected tools include QuickStatements, Mix'n'Match, and Wikidata Lexeme Forms; users of these and other tools may see more pages being added to their watchlists now. (This only applies to new edits and page creations; previously created or edited pages will not be automatically added to the watchlist retroactively.)
    • Working on the basic building blocks of the Query Builder towards making it possible to create the first very simple query with it
    • Talking to people about comparing Wikidata's data against other databases and flagging mismatches
    • Fixing an issue with Item creations via the API by blocked users leading to skipped entity IDs (phab:T232620)
    • Fixed an input issue with invisible characters (phab:T261071)
    • Finishing the draft of the REST API spec to get it ready for feedback
    • WikibaseManifest: created a separate key for local entities and decided what we do about non-local entity sources based on tool-builder feedback (phab:T263527) and specifying the API in OpenApi format (phab:T262919)


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

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

  • Los administradores (sysop) pueden ver las diferencias de ediciones eliminadas en el Registro del filtro antiabusos. Usa la interfaz de Restaurar páginas. [5]
  • Los editores son agregados automáticamente a algunos grupos de usuarios. Por ejemplo, hay editores que son agregados a usuarios autoconfirmados cuando han editado por suficiente tiempo y poseen un mínimo de ediciones. Los filtros antiabusos puede impedir que los usuarios sean agregados a dichos grupos por un tiempo. Además, los filtros puede eliminar este grupos a los usuarios. Las comunidades pueden solicitar el cambio del período para su wiki en Phabricator. Actualmente es de 5 días. [6]

Problemas

  • El año pasado algunos filtros antiabusos dejaron de funcionar por un cambio. Si intentaban usar una variable que no estaba definida para la acción, el filtro fallaba. Esto ya ha sido solucionado. [7]

Cambios de esta semana

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

Cambios futuros

  • No puedes ver los enlaces del artículo a otros idiomas desde las páginas de discusión o historiales. Además, no se muestran cuando editas un artículo. Esto podría cambiar, pero no está decidido si, por ejemplo, el historial de una página debe enlazar al historial de otra página o al artículo. Puedes participar de la discusión en Phabricator.
  • Los colores de los enlaces cambiarán. Esto se permitirá que se diferencie más fácilmente entre los enlaces y otro tipo de texto. Puedes leer más en Phabricator.
  • En tus preferencias puedes elegir recibir diferentes notificaciones por la web o por correo electrónico. Durante esta semana estará disponible la opción de Aplicaciones (Apps) como una de las alternativas. Esto se debe a que las aplicaciones de Wikipedia para Android y iOS usarán notificaciones push para las personas que lo deseen. Puedes ver las preferencias en la wiki de pruebas. El objetivo es tener las notificaciones push en Android durante octubre y en iOS a inicios del 2021. [8]
  • Próximamente podrás poner una página en tu lista de seguimiento por un tiempo limitado. Esto es útil si deseas seguir una página por algún tiempo pero no la quieres en tu lista de seguimiento para siempre. Se encuentra funcionando en mediawiki.org y próximamente se habilitarán en más wikis. Puedes leer más aquí y ver cuándo se implementarán en las otras wikis.
  • Ya puedes revisar cuáles son las mejores herramientas técnicas de este año según los wikimedistas. También puedes nominar herramientas si lo deseas.

Noticias técnicas preparadas por escritores de Noticias Tec y publicadas por un bot • Contribuya • Traduzca • Obtenga ayuda • Denos su opinión • Suscríbase o cancele su suscripción.

21:23 28 sep 2020 (UTC)

Formato de fecha en las referencias (de nuevo)

Quisiera retomar este tema que ya se abordó hace unos meses en un hilo ya archivado. Por recapitular, según el manual de estilo las fechas deben estar en formato largo. Sin embargo muchísimas fechas en las referencias están en formato ISO yyyy-mm-dd especialmente porque así es como las crea el creador de citas del editor visual. Actualmente BenjaBot convierte las fechas de las citas al formato recomendado.

He investigado un poco cómo solventar esto técnicamente y he llegado a las mismas conclusiones del hilo anterior. Las citas se crean a partir de una URL con un servicio llamado Citoid, y este devuelve las fechas siempre en formato ISO, y no tienen intención de adaptarlo. A continuación el editor visual mapea los datos devueltos por Citoid a la plantilla correspondiente, usando la información de TemplateData sin aplicar ninguna transformación. Modificar el editor visual para que transforme el formato de la fecha en este paso sería muy engorroso y dudo mucho que se aceptara tal cambio. Por tanto, la mejor opción, tal y como además sugieren en Citoid, es modificar las plantillas de citas para que sea ahí donde se realice la transformación de la fecha a la hora de mostrarla, manteniendo la fecha en formato ISO a nivel interno. Esto no debería ser excesivamente complicado, creo que ya se hace alguna transformación con el campo idioma por ejemplo.

Las plantillas de citas son complejas y solo pueden editarlas bibliotecarios, así que queda fuera de mis competencias. Lo que sí podría hacer es modificar el bot para que deje de transformar las fechas en formato ISO en las citas, ahorrando muchas ediciones. Menciono a los intervinientes del anterior hilo: Valdemar2018, Geom, Ebergerz, Vanbasten_23, Leoncastro y Ninovolador. Un saludo. --Benjavalero (discusión) 08:23 29 sep 2020 (UTC)[responder]

Se que esto está muy por encima de mí pero coincido que es la mejor manera de solucionar la situación. Por eso he estado implementando en Módulo:Citas/zona de pruebas unos cambios de prueba que permitan a las plantillas aceptar cualquier fecha y mostrar siempre el formato correcto. Lo hago usando Módulo:DateEng que aunque todavía no está 100% listo para usarse en 'producción' es capaz de manejar fechas d.C. sin problemas. En Plantilla:Cita web/zona de pruebas se muestra el resultado. josecurioso ❯❯❯ Háblame! 13:15 29 sep 2020 (UTC)[responder]
Fantástico. @josecurioso: por favor, cuando esto esté en producción avísame para saber qué formatos de fecha tiene que dejar de convertir el bot, aunque el que más interesa que funcione es el ISO (yyyy-mm-dd). --Benjavalero (discusión) 15:09 29 sep 2020 (UTC)[responder]
@josecurioso: también me sumo a esto, ya que mi bot (BOT-Superzerocool) también hace esas correcciones. Superzerocool (el buzón de msg) 15:35 29 sep 2020 (UTC)[responder]
Ya he terminado con las abreviaturas de antes/después de Cristo en las fechas. Con esto todas las plantillas que dependan de Módulo:Citas ya estarían corregidas. Aún así por ahora el código está en la zona de pruebas y preferiría que alguien con más experiencia lo revise antes de incorporarlo a algo tan delicado como ese módulo. Las plantillas afectadas serían {{Obra citada}}, {{Cita publicación}}, {{Cita entrevista}}, {{Cita noticia}}, {{Cita notas audiovisual}}, {{Cita tesis}}, {{Cita libro}}, {{Cita web}} y {{Cita enciclopedia}}. josecurioso ❯❯❯ Háblame! 23:40 29 sep 2020 (UTC)[responder]
@Benjavalero: el módulo traga casi cualquier formato de fecha, incluidos el ISO y el formato actual "X de X de X". josecurioso ❯❯❯ Háblame! 23:45 29 sep 2020 (UTC)[responder]
@Benjavalero: Esto está muy por encima de mis conocimientos técnicos pero me parece una excelente propuesta y francamente creo que sería muy util ya que permitiría utilizar el formato ISO y al mismo tiempo satisfacer la necesidad de usar la fecha en formato largo. (y vuelve irrelevante otras interpretaciones del manual de estilo como la mia). Gracias de antemano por tu trabajo en el módulo. --Ebergerz (discusión) 02:51 30 sep 2020 (UTC)[responder]
Me parece lo más adecuado en todo sentido. Voy a cooperar con hacer algunas pruebas. Saludos --Ignacio Rodríguez - δ -- contr. 20:16 30 sep 2020 (UTC)[responder]
@josecurioso: encontré un problemilla. Cuando la fecha tiene una precisión menor que un día (mes, año, etc...) da un error. Mira esta edición. Estimo que este problema va a ocurrir en miles de páginas, porque las revistas académicas tienen sus fechas en meses o años. --Ignacio Rodríguez - δ -- contr. 20:21 30 sep 2020 (UTC)[responder]
@Ignacio Rodríguez: muchas gracias por el aviso. El módulo que utilizo para manejar las fechas necesita como mínimo día, mes y año así que he cambiado el código para no transformar las fechas si el módulo da error por falta de datos y simplemente retornar el mismo valor que recibe. Esta 'solución' no es ideal porque significa mantener la situación actual de que cualquier cosa que le pongas en un campo de fecha se da por válida. Puede que esto me lleve un tiempo pero voy a ponerme a implementar fechas parciales en el módulo para poder aceptar menor precisión manteniendo cierto grado de validación a las fechas. josecurioso ❯❯❯ Háblame! 21:14 30 sep 2020 (UTC).[responder]
@josecurioso: La casuística de las fechas de las referencias es tremenda. Hay muchos casos por ejemplo que incluyen el día de la semana, por ejemplo «lunes, 3 de julio de 2006» Moneda (divisa). O casos de referencias importadas donde los meses están abreviados de muy diversas formas o lenguas. No me parece mala idea arrojar un error al parsear la fecha, pero quizá de momento sería mejor mostrar el valor tal cual si hay dudas en su transformación. O mejor aún, no sé si se puede, en caso de error mostrar el valor actual y también la advertencia de fecha mal formada. Puestos a pedir, quizá esto se podría ir implementando poco a poco, empezando por las ISO, comprobando con una expresión regular el formato de la fecha a transformar, aunque no sé cómo afectaría esto al rendimiento de la plantilla. En cualquier caso de momento voy a dejar de ejecutar el bot. Muchísimas gracias por tu esfuerzo. --Benjavalero (discusión) 05:55 1 oct 2020 (UTC)[responder]

Incorporación de fotos

Estoy desarrollando una nueva página (Uno de abajo) en Mi Taller (Javier senior) y necesito incorporar fotos. Al efecto he usado el ícono de Imágenes y Multimedia. Me aparece un recuadro en rojo con el nombre de la foto. No encuentro el camino para que suba. Agradeceré ayuda. He revisado instrucciones y la verdad no las manejo.Gracias — El comentario anterior sin firmar es obra de Javier senior (disc. • contribs • bloq). 22:04 30 sep 2020‎

Javier senior (disc. · contr. · bloq.): lee Ayuda:Imágenes. --Леон Поланко говорит вам и слушает вас 01:40 2 oct 2020 (UTC)[responder]
Javier senior (disc. · contr. · bloq.): añado: Ayuda:Tutorial (imágenes). --Леон Поланко говорит вам и слушает вас 00:04 4 oct 2020 (UTC)[responder]

IPv6 desde mi cuenta móvil

Hace un par de horas edité una página desde mi móvil, tras acceder a mi cuenta. De nuevo delante del ordenador, acabo de comprobar el historial del artículo y aparece una dirección IPv6 y no mi nombre de usuario. He vuelto a comprobar el móvil y en efecto estoy todavía conectado a mi cuenta, es decir que no se había desconectado por error antes de publicar la edición. Ya que me interesa que mi nombre aparezca en las ediciones que hago, y es posible que próximamente tenga que hacer más ediciones desde el móvil, me gustaría saber cuál podría ser el problema. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 09:03 1 oct 2020 (UTC)[responder]

Otra vez, problemas en mi sesión

En seguimiento en Phabricator

Tras aproximadamente 8 a 9 años sin ocurrir esto, este año ha ocurrido por lo menos dos veces, el cierre de mi sesión de usuario sin haber clickeado salir. Se cierra mi sesión sin hacer click para salir, y al retroceder a página anterior, no aparecen los links de mi sesión abierta, me aparece al intentar editar el aviso de que no estoy registrado o no he iniciado sesión que aparece a los editores anónimos. Esto no es nuevo, ya me había pasado varias veces entre 2009 y 2011-2012. Menciono dos hilos del café donde comenté el problema:

  1. Problemas en mi sesión, mayo 2010, cuando abrí este hilo, nadie respondió y se archivo sin solucionar y persistió el problema.
  2. Problemas en mi sesión, enero 2011, en este si hubo comentarios.

Ya había pasado tiempo de no ocurrir, y aunque no es a cada rato, considero que no es normal lo que pasa. Añado además, como dos o tres veces también ha ocurrido, inicio sesión, me rebota con unas palabras en rojo, y me regresa a la especial de iniciar sesión, no inició sesión. ¿Alguién sabe si está pasando algo para que la sesión se cierre automáticamente, o que se rebote el inicio de sesión? --Леон Поланко говорит вам и слушает вас 01:48 2 oct 2020 (UTC)[responder]

A mi también se me cerró la sesión el día de hoy. Creo que es por el cambio de mes. Saludos.--Malvinero10 (discusión) 01:53 2 oct 2020 (UTC)[responder]
Malvinero10 (disc. · contr. · bloq.): dudo que tenga que ver el cambio de mes, porque en veces anteriores me ha ocurrido en algún punto intermedio del mes, no necesariamente en principios o finales del mes. ¿Podría ser algún mantenimiento de software? --Леон Поланко говорит вам и слушает вас 01:56 2 oct 2020 (UTC)[responder]
Leonpolanco No te sabría decir, compañero. Yo pensé que era el cambio de mes porque mi sesión había cerrado cerca el inicio del primero de octubre en la hora universal, que son tres horas adicionales sobre la hora de la Argentina. Jaja, pero mirá la vuelta que le dí.--Malvinero10 (discusión) 02:00 2 oct 2020 (UTC)[responder]
Lo más probable es que hayan cerrado todas las sesiones por algún problema de seguridad. Pasó hace unos meses también. Nada especial. --Ignacio Rodríguez - δ -- contr. 02:44 2 oct 2020 (UTC)[responder]
phab:T264370--SRuizR ¡Pura vida! 02:54 2 oct 2020 (UTC)[responder]
Acabo de entrar en Wikipedia y me pide mi usuario y contraseña, hoy es el día 2 así que no veo relación con el cambio de mes pero tampoco lo veo tan dramático. Habrán hecho algo en el sistema, cosas que ocurren (mientras no se repita). En mi caso no es la primera vez ya que hace un mes el Windows se actualizó y al acceder el día siguiente llegué a esa misma pantalla. God bless 1Password. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 04:24 2 oct 2020 (UTC)[responder]
  • Según se ve en el hilo de Phabricator, se ha procedido a desconectar a todos los usuarios por un posible problema de seguridad, quizá relacionado con una nueva versión recientemente desplegada de MediaWiki. Posiblemente esto también esté relacionado con el problema descrito en la sección anterior. Un saludo. --Benjavalero (discusión) 06:14 2 oct 2020 (UTC)[responder]
No es la primera vez que desconectan a todos los usuarios, y seguramente tampoco será la última. Es una medida de seguridad bastante común y normal —al contrario de lo que pueda pensar Leonpolanco—. No hace falta irse al 2009 o 2012, pues la última vez que ocurrió —que yo recuerde— fue hace unos meses (a finales de junio). En el sistema MediaWiki solamente se desconectan a los usuarios cuando hay reportes de incidencias o actualizaciones de software que lo requieran, pero en muchos otros sitios de internet tienen programada la desconexión cada 1, 3, 6 o 12 meses desde el último ingreso, como medida de protección que garantiza que el usuario que está usando la cuenta es su legítimo propietario, y no cualquier otro que se encontró un equipo ya conectado. No hay por qué preocuparse. -- Leoncastro (discusión) 13:54 2 oct 2020 (UTC)[responder]
Me pregunto que tipo de mantenimiento requeriría hacer que las sesiones de usuario vigentes en el momento tengan que ser cerradas. --Леон Поланко говорит вам и слушает вас 20:09 2 oct 2020 (UTC)[responder]
Es muy posible que este tipo de desconexiones tienen que ver con el cambio en las semillas de seguridad que cifran los tokens de sesiones que usamos para estar en la web: si hay una filtración o problema con los tokens, se cambia la semilla y todas las sesiones viejas ya no son operativas, ya que ha cambiado el cifrado. Eso especulo. Superzerocool (el buzón de msg) 20:21 2 oct 2020 (UTC)[responder]
Cuando vayan a hacer este tipo de mantenimiento ¿no sería buena idea avisar anticipadamente? Como avisaron en julio de 2018 cuando bloquearon wikipedia el 4 de julio de aquel año. --Леон Поланко говорит вам и слушает вас 00:05 4 oct 2020 (UTC)[responder]

┌─────────────────────────────┘
Concuerdo con Leonpolanco. Sería bueno poner un banner como suelen hacer con otras cosas cuando hagan esto para evitar tanta confusión.--SRuizR ¡Pura vida! 00:28 4 oct 2020 (UTC)[responder]

En aquel entonces (2009, 2010) ya ocurría esto ¿era más frecuente por aquel entonces? Porque por aquella época mi sesión se me cerraba con mayor frecuencia que actualmente. ¿Que dices Superzerocool (disc. · contr. · bloq.)? Porque tu ya estabas en ese entonces en Wikipedia. --Леон Поланко говорит вам и слушает вас 18:44 4 oct 2020 (UTC)[responder]
No recuerdo que fuese tan seguido, pero sí se producía de vez en cuando (una o dos veces por año). En este caso, el deslogueo forzado se realiza por temas de seguridad. Esperemos que los desarrolladores de Mediawiki lo pillen pronto. Superzerocool (el buzón de msg) 00:34 5 oct 2020 (UTC)[responder]

Wikidata weekly summary #436

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
  • Events
    • Upcoming: Next Linked Data for Libraries LD4 Wikidata Affinity Group call: Professor Toby Hudson on Entity Explosion, a browser extension which allows you to get information about entities on the web page you’re visiting, 06 October. Agenda
    • Upcoming: Wikidata & Wikibase office hour, October 27th at 17:00 CEST (15:00 GMT)
    • Upcoming: plenty of events for the Wikidata birthday, check the calendar and feel free to organise one!
  • Tool of the week
    • IllWill.js is a userscript that searches Wikidata for foreign-language sitelinks, to populate Template:ill and replace plain red links on other Wikimedia projects.
  • Other Noteworthy Stuff
    • omeka-s-wikidata is a new module for the open source GLAM collection management software Omeka, that allows cataloguers to use Wikidata as a vocabulary for persons, places, subjects, etc.
  • Development
    • First pieces of the Query Builder are coming together and we are working towards making it generate the first dumb query
    • Talking to people about their thoughts on checking Wikidata's data against other databases. If you're interested reach out to Mohammed.
    • Got some first internal feedback for the REST API specification draft. We'll publish it for feedback in the next days.
    • Fixing an issue with certain language codes no longer being available (phab:T264294)
    • Working on making sure blocked bots don't waste Item IDs when trying to create new Items (phab:T232620)

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

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

  • Se ha creado una herramienta nueva que permite visualizar las wikis de origen (home wikis) de los participantes en una discusión en Meta. Ello permite detectar el nivel de participación en discusiones relativas a decisiones que afectan a múltiples proyectos.
  • Ahora puedes agradecer a los usuarios cuando suban un archivo o cambien el idioma de una página. [9]

Problemas

  • Se tuvo que revertir la instalación de la última actualización semanal de MediaWiki debido al alto número de errores registrados, por lo que los cambios previstos para la semana anterior serán instalados con retraso. [10]
  • Todas las sesiones de usuarios fueron cerradas debido a que algunos usuarios podían navegar por la wiki como si estuvieran en la cuenta de otro usuario. El problema ya fue resuelto. [11]
  • Elemento avanzado Existen muchas páginas con errores de JavaScript. Puedes leer más acerca de ello o ver la lista de páginas de usuario con errores.

Cambios de esta semana

  • Elemento recurrente La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 6 octubre. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 7 octubre, y en las restantes a partir del 8 octubre (calendario).
  • Letters immediately after a link are shown as part of the link. For example the entire word in [[Child]]ren is linked. On Arabic wikis this works at both the start and end of a word. Previously on Arabic wikis numbers and other non-letter Unicode characters were shown as part of the link at the start of a word but not at the end. Now only Latin and Arabic letters will extend links on Arabic wikis. [12]

Cambios futuros

Noticias técnicas preparadas por escritores de Noticias Técnicas y publicadas por un bot • Contribuya • Traduzca • Obtenga ayuda • Denos su opinión • Suscríbase o cancele su suscripción.

16:24 5 oct 2020 (UTC)

Bucle de pantalla

He creado para un Wikiproyecto una página de las pestañas/lengüetas que quiero colocar como plantilla en la cabeza de cada página accesible a través de una de las pestañas. De este modo no habrá que cambiar todas las cabeceras cada vez que quiera añadir o quitar algo en las pestañas (sobre todo ahora que estoy experimentando).

El problema es que lo reconoce como bucle de pantalla ya que, por ejemplo, si coloco la plantilla en la página principal en efecto la primera pestaña incluye esta página, y así será para todas. Pero en realidad no es así ya que cuando se incluye el código de la pestañas enteramente en la página principal, por ejemplo, no aparece un enlace sino una letra en negrita sin enlace, como suele pasar siempre cuando se inserta en una página un enlace a la misma. Por eso no entiendo para qué sirve eso del bucle ni cómo solucionar este problema sin tener que introducir el código de pestañas en cada página. Programáticamente es como si me quitasen las subrutinas diciéndome que no puede ser. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 06:45 6 oct 2020 (UTC)[responder]

Retiro mi consulta. Aunque aún no entiendo el por qué, en el caso de las pestañas también se trataría de adaptación del diseño, así que ya lo hago manualmente. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦   🗣 07:33 6 oct 2020 (UTC)[responder]

Archivos multimedia en es.wikipedia o acceso indirecto a Commons desde es.wikipedia

Pido perdón por adelantado si esta consulta corresponde a otra sección, espero no haberme equivocado, me ha parecido una duda técnica fundamentalmente... Querría saber si sería posible activar el almacenamiento de archivos audiovisuales en es.wikipedia como tienen las enciclopedias en otros idiomas (la inglesa seguro, creo que alguna otra también) o si existe alguna herramienta que desde es.wikipedia permita colocarlos en Commons sin que el usuario tenga que interactuar con Commons (aunque lo haga la herramienta). Aporto algunos ficheros de este tipo para la enciclopedia, pero no voy a volver a Commons y en en.wikipedia ya no me permiten colocar ficheros para pasarlos de ahí a Commons para poderlos usar en la enciclopedia española, así que tengo la duda entre si hay posibilidad (en principio, técnica) de colocarlos bien directamente en es.wikipedia o en Commons desde es.wikipedia o si me olvido de contribuir este material a la enciclopedia. Gracias a todo el que me pueda aclarar si es posible o no...--Rowanwindwhistler (discusión) 11:41 6 oct 2020 (UTC)[responder]

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