Diferencia entre revisiones de «Wikipedia:Café/Archivo/Técnica/Actual»
Etiqueta: editor de código 2017 |
|||
Línea 346: | Línea 346: | ||
::: {{ping|Benjavalero}} el módulo traga casi cualquier formato de fecha, incluidos el ISO y el formato actual "X de X de X". <span style="background:#5c5c5c;padding:2px 12px;font-size:12px">[[Usuario:josecurioso|<span style="color:#fff">josecurioso</span>]] <span style="color:#FC0">❯❯❯</span> [[Usuario_discusión:josecurioso|<span style="color:#fff">Háblame!</span>]]</span> 23:45 29 sep 2020 (UTC) |
::: {{ping|Benjavalero}} el módulo traga casi cualquier formato de fecha, incluidos el ISO y el formato actual "X de X de X". <span style="background:#5c5c5c;padding:2px 12px;font-size:12px">[[Usuario:josecurioso|<span style="color:#fff">josecurioso</span>]] <span style="color:#FC0">❯❯❯</span> [[Usuario_discusión:josecurioso|<span style="color:#fff">Háblame!</span>]]</span> 23:45 29 sep 2020 (UTC) |
||
::::{{ping|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. --[[Usuario:Ebergerz|Ebergerz]] ([[Usuario Discusión:Ebergerz|discusión]]) 02:51 30 sep 2020 (UTC) |
::::{{ping|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. --[[Usuario:Ebergerz|Ebergerz]] ([[Usuario Discusión:Ebergerz|discusión]]) 02:51 30 sep 2020 (UTC) |
||
:::::Me parece lo más adecuado en todo sentido. Voy a cooperar con hacer algunas pruebas. Saludos --[[User:Ignacio Rodríguez|'''Ignacio Rodríguez''']] <span style="background-color:lightgreen; color:white;border-radius:0 10px 10px 0"> [[User talk:Ignacio Rodríguez|- δ -]][[Special:Contributions/Ninovolador|- contr.]]</span> 20:16 30 sep 2020 (UTC) |
Revisión del 20:16 30 sep 2020
Café: Técnica | ||
---|---|---|
En esta sección del Café de Wikipedia puedes plantear cuestiones técnicas de edición de páginas de Wikipedia.
|
Café | |
---|---|
Noticias | [+] |
Políticas | [+] |
Técnica | [+] |
Propuestas | [+] |
Ayuda | [+] |
Miscelánea | [+] |
Ver todos | |
|
Fusión de historiales: copiar contenido de un lado a otro
Esto es algo en el que he puesto un poco más de atención en el último tiempo, sobre uno de los pasos para hacer una Fusión de historiales: ambos artículos deben ser iguales, cosa que no entiendo por que si, técnicamente, al fusionar, la versión más reciente quedará visible. De hecho, la documentación de MediaWiki no dice nada acerca de eso.
El problema viene que algunos bibliotecarios rechazan solicitudes de fusión de historiales porque las páginas difieren, en especial cuando se está editando activamente una página al momento de hacer la solicitud en el TAB.
Si bien no he leído (mucho) el código fuente de MediaWiki ni la documentación más esotérica, ni tampoco se cómo se utiliza la fusión de historiales, entiendo cómo funcionan varios aspectos técnicos, por lo que, para mi, ese paso me parece un tanto innecesario, o cuanto menos, que se exija. Se supone que los bibliotecarios deberían tener alguna noción básica de cómo funciona MediaWiki en ciertos aspectos, más allá de las instrucciones sobre procedimientos con sus botones. -- Davod (desquítense n_n) 03:58 11 ago 2020 (UTC)
Actualización: Ya vi cómo funciona la fusión de historiales, y sí, es un verdadero dolor de cabeza, entiendo a los biblios. En Phabricator hay una tarea que pide esas características desde enero de 2019, pero está estancada. Pienso que algún bibliotecario debería comentar ahí y exponer el "dolor" que representa hacer una tarea tan básica en sus funciones.
Otra cosa, en Wikipedia en inglés la hicieron fácil y optaron por dejar una redirección en lugar de fusionar historiales. ¿Qué opinan al respecto? -- Davod (desquítense n_n) 16:27 11 ago 2020 (UTC)
- Depende del orden en que lo hagas. Sean X e Y dos artículos para fusionar en X, con contenido distinto. Tienes dos caminos. El largo para el bibliotecario es trasladar de X a Y, borrar, fusionar historiales y trasladar a X (4 pasos). El corto para el bibliotecario es que quien pide la fusión copie el contenido en Y y así solo haya que trasladar a X, borrar y fusionar historiales (3 pasos). Si no se hace esto, al trasladar desde Y a X, borrar y fusionar, quedará el contenido que no era (3 pasos, pero mal). La diferencia en 1 paso puede parecer mínima, pero la mayor cantidad de errores se produce en los traslados (si no recuerdo mal, una vez borré "Idioma español" y más encima perdí los historiales en una página mal nombrada :P , otro bibliotecario tuvo que hacer tejemanejes ingeniosos para salvarlo todo sin perder ni mezclar los historiales). Así que el pedido de fusión de contenido es para que la persona eche una mano en reducir la posibilidad de errores. Yo rechazo las fusiones de historiales cuando el artículo que queda no ha incorporado lo incorporable del otro. Saludos. Lin linao ¿dime? 04:13 11 ago 2020 (UTC)
- ¿Y no sería más simple hacer simplemente la fusión de historiales y ya, y revertir a la edición más reciente que se desea? Yo creo que en ese caso habría que pedir a los desarrolladores de MediaWiki una característica que permita establecer alguna revisión específica en el historial como la revisión más reciente. -- Davod (desquítense n_n) 04:34 11 ago 2020 (UTC)
- Desconozco la historia de esta "directriz", pero me imagino que se habrá hecho como un paso adicional para asegurar que quien lo solicita ha acabado con los demás pasos de la fusión de artículos. Algo como una confirmación, porque lo más fácil es solicitar la fusión y que los admin ya se encarguen de hacer el trabajo de comprobarlo todo. Durante la fusión de artículos se supone que tienes que hace cierto trabajo - como mínimo comprobar que toda la información de uno está también en el otro, y si no tienes suerte también copiar secciones, editarlas, asegurarte de que encajen bien en el texto, quitar redundancias, repasar las referencias, etc. Si haces todo eso, el último paso del copy-paste es lo último que importa, créeme, de hecho te da una sensación de satisfacción, sabiendo que has terminado algo complicado, y los admin, a través de esta acción, también lo entienden. Y aunque no hayas tenido que copiar nada o se trata de un artículo corto, en este caso una sola acción tampoco sería pedir demasiado. De experiencia te digo que cuando la gente tiene que trabajar para conseguir algo, menos se le ocurre sencillamente solicitarlo y seguir adelante sin haber hecho nada ni comprobado nada (a veces hasta ni leyendo el artículo entero), dejando todo el trabajo a quien atiende la petición. Ya me imagino yo a ciertos usuarios repasando las listas de artículos a fusionar y bombardeando la página de fusión de historiales, que no les cuesta nada. En cuanto a que "algunos bibliotecarios rechazan solicitudes de fusión de historiales porque las páginas difieren", creo que es obvio, si existe dicha pauta (y hasta se subraya en negrita) entonces se sigue. Si fuera opcional, vale, pero si es parte de los pasos a seguir, obviamente se exige. 𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦 🗣 05:41 11 ago 2020 (UTC)
- ¿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)
- No, no es más simple, porque quien "desea" que quede en una edición particular es el que pide la fusión. Entonces lo más simple es que él mismo lo deje como lo quiera y que el bibliotecario no tenga que preocuparse de ese detalle y pueda encarar la fusión como le parezca mejor. Además, se evitan malos entendidos y potenciales errores, y no cuesta tanto, ¿no? Saludos. --angus (msjs) 12:18 11 ago 2020 (UTC)
- Hago fusiones todo el tiempo, y ese requisito me ahorra mucho tiempo: aunque técnicamente es indistinto el contenido inicial del artículo de destino, si un usuario confiable –los poco confiables no suelen hacer estos pedidos, aunque hay excepciones– hace una solicitud y veo que tiene el mismo número de bytes, lo hago sin revisar nada: 20-30 segundos de trabajo. Si hay una diferencia de bytes, tengo que ir a revisar ambos artículos, compararlos, ver cuál es la diferencia, cuál de los dos es la correcta, corregir todo y volver al TAB a hacer la fusión: 5 a 15 minutos de trabajo. O, dicho de otra forma, varios hilos del TAB que quedan sin responder. Saludos. --Marcelo (Mensajes aquí) 15:06 11 ago 2020 (UTC)
- El detalle aquí es que soy yo el que quiero hacer la fusión, y he seguido los pasos. En el caso particular de WarnerMedia Latin America → Turner Broadcasting System Latin America, ya propuse la fusión y lo había discutido en la página de discusión, por lo que ambos artículos son casi idénticos, casi, por que ambos están siendo editados en paralelo, y eso jamás se resolverá con tanta demora en atander a la solicitud de fusión de historiales que hice en el TAB (razón por la cual le pedí el favor a Usuario:Marcelo de atender la solicitud), y, como WarnerMedia Latin America es un copia/pega de Turner Broadcasting System Latin America, y, como no es una reestructuración tan compleja como lo es Turner Broadcasting System → WarnerMedia Entertainment y WarnerMedia News & Sports, no veo la necesidad de separar historiales. -- Davod (desquítense n_n) 02:15 12 ago 2020 (UTC)
- Pregunta: ¿Porqué ya no se usa Special:MergeHistory?--SRuizR 17:43 11 ago 2020 (UTC)
- Por lo que he visto, la única herramienta disponible (al menos en una instalación vanilla de MediaWiki) es la extensión MergeHistory. -- Davod (desquítense n_n) 02:15 12 ago 2020 (UTC)
- R, no la conocía o no la recordaba. La probé y solo funciona cuando los dos historiales no se superponen en el tiempo, la última edición del artículo fusionado tiene que ser más antigua que la primera del artículo que queda. Así que tiene utilidad para un número reducido de casos. Gracias y saludos. Lin linao ¿dime? 03:59 13 ago 2020 (UTC)
- Pregunta: ¿Porqué ya no se usa Special:MergeHistory?--SRuizR 17:43 11 ago 2020 (UTC)
Para facilitar la labor de los sysop, he propuesto lo siguiente en Phabricator:
- Listar el historial de ambas páginas a través de Especial:MergeHistory y permir seleccionar qué ediciones fusionar (todas por defecto), y permita seleccionar una revisión específica para que pase a ser el contenido visible una vez hecha la fusión (la última revisión de la página de destino por defecto).
- Permitir fusionar historiales a través de Especial:MovePage, dejando la última revisión de la página de destino como la página visible por defecto, agregar la casilla de verificación "Fusionar historial" en adición a "Eliminar página de destino", junto con un enlace a Especial:MergeHistory para opciones de fusión avanzadas.
Invito cordialmente a los bibliotecarios a comentar en la tarea de Phabricator que enlacé. -- Davod (desquítense n_n) 04:41 13 ago 2020 (UTC)
- "
Invito cordialmente a los bibliotecarios a comentar en la tarea de Phabricator que enlacé
": good luck with that. strakhov (discusión) 20:31 14 ago 2020 (UTC)
- "
Categorías de Wikipedia en otro idioma
Buenas tardes. Soy nuevo en Wikipedia y tengo una duda sobre la categorización. Quería saber si existe alguna forma de colocar una categoría que es originaria de Wikipedia en italiano, en un artículo de Wikipedia en español. Busqué en varios artículos pero no encuentro ayuda al respecto. Gracias. --Emiliano.SM (discusión) 19:55 15 sep 2020 (UTC)
- Hola, por lo general se pueden buscar en las categorías en italiano en el cuadro de In altre lingue cuando vistas una página de una categoría (por ejemplo esta categoría presenta que solo hay una categoría igual en sueco). No necesariamente hay equivalencia entre categorías entre todas las wikis, por lo cual es posible que no exista una categoría en español. Las categorías, y su equivalencia, son llevadas en Wikidata. Saludos! Superzerocool (el buzón de msg) 22:20 15 sep 2020 (UTC)
- Supongo que se podría crear la categoría en la wiki española, siempre que existan suficientes artículos para categorizar. --Леон Поланко говорит вам и слушает вас 19:28 19 sep 2020 (UTC)
Plantilla:Usuario taller+
La plantilla dejo de funcionar adecuadamente de un día para otro, no la veo vandalizada. A nuestros estimados expertos en plantillas por favor solucionar el inconveniente. Gracias de antemano!!! Esteban (discusión) 12:23 17 sep 2020 (UTC)
- también lo he detectado, y al problema se suma que aparecen categorías en esas páginas que tienen la plantilla... catagorías como: Aeropuertos de Atlántico (Colombia), Edificios y estructuras de Barranquilla, Transporte de Barranquilla; Aeropuertos inaugurados en 1979. Muchas gracias de antemano.--Florenciac (discusión) 12:26 17 sep 2020 (UTC)
- @Ezarate, @Florenciac, estaba vandalizada otra de las plantillas que usa internamente. Ahora ya está resuelto. PD: Esteban, si le pones una semi o una full, mejor. -- Leoncastro (discusión) 14:36 17 sep 2020 (UTC)
- Gracias Leoncastro, otra de las plantillas que parece hecha por el enemigo, inseguible!! Esteban (discusión) 14:44 17 sep 2020 (UTC)
- @Ezarate, cuando sospeches que pueda ser un vandalismo, en lugar de analizar el código de la propia plantilla (que puede ser inmenso), prueba a revisar los cambios recientes visualizando únicamente el espacio de plantillas (no suele haber muchos movimientos en plantillas, y cualquier cosa nueva suele destacar). -- Leoncastro (discusión) 15:50 17 sep 2020 (UTC)
- Gracias Leoncastro, otra de las plantillas que parece hecha por el enemigo, inseguible!! Esteban (discusión) 14:44 17 sep 2020 (UTC)
- @Ezarate, @Florenciac, estaba vandalizada otra de las plantillas que usa internamente. Ahora ya está resuelto. PD: Esteban, si le pones una semi o una full, mejor. -- Leoncastro (discusión) 14:36 17 sep 2020 (UTC)
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)
- @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)
- Muy bien.--Malvinero10 (discusión) 17:13 21 sep 2020 (UTC)
Wikidata weekly summary #434
- 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
- Press, articles, blog posts, videos
- "Representing COVID-19 information in collaborative knowledge graphs: a study of Wikidata"
- ProWD: Detecting Knowledge Imbalances on Wikidata on blog.wikimedia.de
- Video: Wikipedia Weekly Network - LIVE Wikidata editing #20 WLM: Facebook, YouTube
- Video: Wikidata Training Workshop 3, by Canadian Arts Presenting Association (YouTube)
- Tool of the 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.
- WDQS/WCQS Status update (September 2): "We are planning to spend more time doing some analytics on our data. (1) What are the most expensive queries, what are they trying to achieve and is that reasonable? (2) Do we have performant subgraphs that we could expose independently?"
- Did you know?
- Newest properties:
- General datatypes: category for the exterior of the item, axle track, Stairway To Hell ID, Oakeshott typology, construction point, turning radius, hill size, bibliography
- External identifiers: Seattle Art Museum ID, Nelson-Atkins Museum of Art artwork ID, TV Maze series ID, Barcelona Public art ID, University of Ghana Digital Collections (UGSpace) ID, Istrapedia ID, OnlyFans person ID, Linked Open Data Cloud identifier, The Cutting Room Floor ID, Fatcat ID, China Treaty Database ID, e-GOV law ID, Portugal. Dicionário Histórico ID, past Fellow of the Royal Society ID, Regesta Ecclesiastica Salisburgensia ID, Slack organization ID, Kansas Historic Resources Inventory ID, Historic Montana ID, ITF player ID 2020, BD Gest' series ID, American Battlefield Trust battlefield ID, P8624
- New property proposals to review:
- General datatypes: defining mutations, nombre d'essais marqués, Netflix maturity rating, held event, number of paying subscribers, has census
- External identifiers: Rheinland-Pfälzische Personendatenbank ID, Delft municipal monument ID, identificativo Ministero dell'interno, Dallas Museum of Art ID, Cincinnati Art Museum ID, Energy Identification Code, Wikimedia Chat channel, Symptom Ontology ID, MnDOT Historic Bridges ID, monumentsauxmorts.fr ID, monumentsdememoire.fr ID, Lower Sorbian place name ID, Région Île-de-France ID, Museen Dresden article ID, Turkey's Culture Portal ID, NPS place ID, SSYK 2012
- Query examples:
- Map of anything that memorializes or is named after a Whig Party member - OSM/Wikidata query
- Map of every railway station presently connected directly or indirectly to St Pancras on Wikidata
- Age of the winners of the Tour de France (Source)
- Location and date of death of Danish rulers (Source)
- Map of the places & causes of death of Roman Emperors (Source)
- Images of members of the 16th Odisha Assembly (2019-24) (Source)
- Star signs of Japanese Prime Ministers (Source)
- Video game series with the longest time gap between a game and its direct sequel (Source)
- Newest properties:
- 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.
- Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!
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]
- 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
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)
- 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)
- Hola, creo que está reportado en este ticket en Phabricator. Superzerocool (el buzón de msg) 15:32 23 sep 2020 (UTC)
- 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)
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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
┌─────────────────────────────┘
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)
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)
- 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)
- 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)
- Gracias!!!. --Juan Villalobos (discusión) 22:10 26 sep 2020 (UTC)
- 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)
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)
- 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)
Wikidata weekly summary #435
- Events
- Linking the 20th century paper history to the sum of all knowledge (Best practice presentation at DCMI Virtual 2020)
- Upcoming: live SPARQL queries on Twitch and in French by Vigneron, September 29 at 18:00 CEST
- Upcoming: WikiNeocomensia: Wikidata + OpenRefine, workshop in Neuchâtel (Switzerland) and in French, October 3
- Upcoming: Online Wikidata editathon in Swedish #32, October 4
- Press, articles, blog posts, videos
- The International Federation of Library Associations and Institutions [IFLA] have published a series of six videos "discussions with professionals in order to discuss projects, issues, progress of Wikidata, Wikibase and bibliographic data in the field of libraries." Currently available as a playlist on YouTube under CC-By (Wikimedia Commons upload soon), with subtitles in English, Spanish, Portuguese, and French (Arabic and Chinese coming soon). The production was made by the IFLA Wikidata Working Group and funded by a WikiCite grant.
- Sidestepping the limitations of collection catalogues with machine learning and Wikidata
- Navigating the maze of Wikidata query logs by Angela Bonifati, Wim Martens, Thomas Timm
- Video: Wikipedia Weekly Network - LIVE Wikidata editing #21 - WikiDojo on the Global Climate Strike: Facebook, YouTube
- Video: Wikidata tutorial for lecturers (in Czech) - YouTube
- Video: Creating and enriching linked data with Wikidata - YouTube
- Video: Mix'n'Match Tutorial - YouTube
- Video: Introduction to Wikidata for librarians (in Portuguese) - YouTube
- Tool of the week
- omeka-s-wikidata is an Omeka-S module for auto-suggesting Wikidata URIs and labels.
- 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.
- Did you know?
- Newest properties:
- General datatypes: construction point, turning radius, hill size, bibliography, opening time, closing time, engine displacement, expansion of, Netflix maturity rating, TDD number
- External identifiers: American Battlefield Trust battlefield ID, American Battlefield Trust ID (person), Occupational Outlook Handbook ID, Thomas Jefferson Encyclopedia ID, Canadian Women Artists History Initiative ID, Book Marks ID, Re-Member ID, SPoT skater ID, NDL law ID, McClintock and Strong Biblical Cyclopedia ID, L'Officiel des spectacles ID, British and Irish Furniture Makers Online ID, Cincinnati Art Museum ID, Dallas Museum of Art ID, FBref.com squad ID, Dostoyevsky and His Entourage ID, Lambiek comic magazines ID, Energy Identification Code, Library of Congress Children's Subject Headings ID, Ministry of the Interior of Italy ID, National Park Service place ID, MnDOT Historic Bridges ID, Open Civic Data Division ID, Museen Dresden article ID, SSYK 2012 The Swedish Standard Classification of Occupations, LoC HABS/HAER/HALS place ID, Symptom Ontology ID, photoLondon ID, Syro-Malabar Catholic Church ID
- New property proposals to review:
- General datatypes: Regional Council of Tuscany ID, level of professionalness, defined in terms of, form of property constraint, Attraction to, group identity, analog television standard, ritual object, number of rooms
- External identifiers: USA Water Polo Hall of Fame ID, Encyclopaedia Beliana ID, Indonesian prison database ID, LinkedIn group ID, Naver movie ID, CINE21 film ID, Movist film ID, KOBIS-ID, Max Movie film ID, The Boardr profile ID, Slovník českých nakladatelství 1848-1949 person ID, Google Play developer slug, Passion Patrimoine ID, FVLB work ID, BBC Sound Effects Asset ID, ITHL author ID, Quebec Dams Directory ID, Doktori.hu ID
- Query examples:
- Newest properties:
- 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. (TheVigilar 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)
- 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
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.
- Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!
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
- 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)
- 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)
- 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)
- @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)
- 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)
- 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
- @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)
- @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)
- 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)
- @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)
- @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)
- 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)