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

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda
Café: Técnica
Taza
Icon tools.svg

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


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

Temático

Atajo
WP:C/T




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

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


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

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

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

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

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

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

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

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

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

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

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

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); };[1][2][3] 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)

Nueva funcionalidad: Lista de seguimiento temporal[editar]

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

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

Múltiples "deshechos"[editar]

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

@Virum Mundi: Ayuda:Cómo revertir una edición--SRuizR ¡Pura vida! 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 ¡Pura vida! 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. [4]

Changes later this week

  • There is no new MediaWiki version this week.

Future changes

  • Advanced item 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. [5]

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]

Wikidata-logo-en.svg
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.

Ampliar la plantilla NF a casos particulares de seres humanos[editar]

En la actualidad, la plantilla {{NF}} solo tiene en consideración a los seres humanos (ser humano (Q5)). En este hilo de hace algunos meses, informé de que la plantilla no reconocía a ciertos personajes que, aun siendo considerados ficticios o su historicidad dudosa, siguen teniendo ubicación histórica, la cual se puede rastrear en obras modernas. Los ejemplos que puse fueron Lucio Junio Bruto y Lucio Tarquinio Colatino que podrían ser ser humano ficticio (Q64520857) o ser humano que podría ser de ficción (Q21070568) según las fuentes. Leoncastro encontró también personaje humano bíblico (Q20643955). Probablemente haya más. Lo que propongo es que la plantilla reconozca estos casos. --Romulanus (discusión) 14:13 27 nov 2020 (UTC)

En los casos de personajes ficticios no tiene caso usar la plantilla {{NF}} (Nacido-Fallecido) porque nunca nacieron o fallecieron, creo que el {{Control de autoridades}} está bien para esos casos; respecto a los personajes de historicidad dudosa creo que existe una categoría que se puede añadir de manera conjunta con {{NF}} (personajes de historicidad dudosa o algo así, no recuerdo bien el nombre). Saludos Valdemar2018 (discusión) 14:29 27 nov 2020 (UTC)
Hay diferencias entre ser humano ficticio (Q64520857) y personaje de ficción (Q95074). Para el segundo, no tiene sentido la plantilla, pero para el primero sí. --Romulanus (discusión) 23:46 29 nov 2020 (UTC)
Yo no lo tengo tan claro Romulanus. Es decir, un ser humano ficticio, un personaje que llegó a considerarse persona en algún momento pero que es alguien que realmente nunca existió, por lo que tampoco tuvo nacimiento y fallecimiento reales, y no tengo claro que deba considerarse como una persona. Del mismo modo, algunos personajes bíblicos están documentados como personas reales, mientras otros —como Eva— son personajes de su historia que solamente cuentan como personas reales para la propia historia bíblica. -- Leoncastro (discusión) 15:18 30 nov 2020 (UTC)
@Romulanus: La categoría a la que me refería es Categoría:Personas cuya existencia es discutida, la cual por algún motivo tiene muchas menos páginas de las que debería tener (tal como lo señaló @Leoncastro:, muchos personajes bíblicos son existencialmente cuestionados). Saludos Valdemar2018 (discusión) 15:29 30 nov 2020 (UTC)

Plantilla de premios de música[editar]

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]

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]

Wikidata-logo-en.svg
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

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

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]

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.wikipedia.org/w/index.php?title=Wikipedia:Café/Archivo/Técnica/Actual&oldid=131383035»