Wikipedia:Café/Portal/Archivo/Técnica/2019/02

Archivo

Tech News: 2019-06

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• It was easy to untick a box by accident in Special:Preferences. This will now be fixed. [1]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 February. It will be on non-Wikipedia wikis and some Wikipedias from 6 February. It will be on all wikis from 7 February (calendar).

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 6 February at 16:00 (UTC). See how to join.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

17:11 4 feb 2019 (UTC)

Wikidata weekly summary #350

Here's your quick overview of what has been happening around Wikidata over the last week.

• Events
  • Next Wikidata workshop/meetup in Paris: February 15th
  • Next Wikidata meetup in Berlin: March 12th
  • The conference grant proposal for WikidataCon was submitted and could use endorsements.

• Press, articles, blog posts
  • „Eisberg voraus!“ – Sächsische Landeskunde mit SXRM, Wikisource und Wikidata by Jens Bemme (in German)
  • Linking the OLAC Video Game Vocabulary with Wikidata by Tracy Hoffmann and Peter Chan
  • Adam blogged about how to update an existing Wikibase docker instance

• Other Noteworthy Stuff
  • Got some time? SpeedPatrolling, a tool to simplify patrolling of recent changes on Wikidata (documentation), has been announced and you can use it to help fight vandalism.
  • Got some time? Match some streets and the humans they are named after.
  • Got some time? Help link OpenStreetMap and Wikidata Items with the new OSM <-> Wikidata matcher.
  • Wikidata Query Service now has over 7 billion triples.

• Did you know?
  • Newest properties:
    • General datatypes: affiliation string, RightsStatement status according to source website, trading name, Alexander–Briggs notation
    • External identifiers: DIZIE ID, football.odessa.ua person ID, sport-strana.ru article ID, Homosaurus ID, funk channel ID, GEOFON earthquake ID, Georgian National Filmography ID, infosport.ru person ID, ManualsLib brand ID, MusicBrainz event ID, LGD local body code, HAER ID, Hymnary hymnal ID, Hymnary instance ID, Hymnary tune ID, Global Species ID, Amsterdam code
  • New property proposals to review:
    • General datatypes: does not have quality (2), Den Digitale Byport-ID, expression of, calendar feed url, Total goals in career, Strepsiptera database species ID, Brentidae of the world species ID, Illustrated catalog of Tessaratomidae species ID, WBCHSE code
    • External identifiers: Douban Book ID, Douban Musician ID, Douban Author ID, Douban Music ID, Douban Drama ID, Douban Game ID, Douban Read Author ID, Douban Read eBook ID, Douban Site Name, Douban Username, Zhihu username, Bilibili user ID, QQ number, Bilibili video ID, Bilibili bangumi ID, Bilibili tag ID, Mtime movie ID, Mtime people ID, Dictionary of Anhui Writers ID, Fuzhou Architecture Heritage ID, Eventa Servo ID, Rocks Backpages author ID, Rocks Backpages artist ID, Rocks Backpages publication ID, Hulu movie ID, Hulu series ID, Democracy Club ID, ISA ID, Mecklenburg-Vorpommern Schutzgebiete-ID, DALFAN ID, GameFAQs franchise ID, CABB player ID, castingvideos ID, Bildarchiv, Herder-Institut, IEEEXplore document ID, IEEEXplore author ID, Antarctica NZ Digital Asset Manager, Pacific Coast Architecture Database building ID, Twitter user ID, Australian Antarctic Data Center, Enciclopedia delle donne ID
  • Deleted properties: P1112 (Pokédex number)
  • Query examples:
    • Common topics of publications by people affiliated with a given organization
    • World __ days and other awareness days in calendar order (Source)
    • timeline of writing systems (source)
    • family tree of Donald Duck (source)
    • Common long words in titles of scholarly articles (source)
    • schools of magic by number of students (source)

• Development
  • Making progress towards first showable version of basic Shape Expression support
  • Layout polishing for the mobile termbox (the box that shows labels, desctiptions and aliases) and continuing work on the "in more languages" and "all entered languages" sections in it
  • Added tracking for the number of Senses and Forms to our graph for tracking the number of Items, Properties and Lexemes
  • Worked more on making it easier to set up Quickstatements in other Wikibase instances
  • Preventing an entity to redirect to itself (phabricator:T214919)
  • Working on making Federation (reusing Wikidata's Items and Properties to make statements) work for Wikimedia Commons to get the rollout of the next stage (support for depicts statements) unstuck
  • Fixed an issue with adding sitelinks from Commons (phabricator:T213975)
  • Fixing Cognate support for yue Wiktionary (phabricator:T214400)

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Suggested and open tasks!
  • 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!

Read the full report · Unsubscribe · Lydia Pintscher (WMDE) 21:33 4 feb 2019 (UTC)

Ayuda, plantilla

Hola. Necesito ayuda en saber el nombre de una plantilla ({{}}), es algo así el mensaje: «Este artículo necesita no tener fallas ortográficas. Puedes ayudar a Wikipedia yendo a Preferencias y activa Corrector ortográfico.» Gracias y saludos. --Furawi (discusión) 21:37 6 feb 2019 (UTC)

Furawi: Se trata de la plantilla {{Copyedit}}. Saludos.--Marcos Okseniuk (discusión) 21:46 6 feb 2019 (UTC)

Listas de referencias

Llevo un tiempo planteándome una cuestión. Actualmente hay dos maneras de listar referencias en Wikipedia al final de los artículos, una usando la herramienta que la propia wiki incorpora <references />, y otra la plantilla {{listaref}}, pero alguna vez al insertar <references />, otro editor ha editado el artículo para usar {{listaref}}. Ambas pueden usarse sin problemas tal como se explica en WP:Referencias y aparentemente disponen de las mismas funcionalidades, pero {{listaref}} parece que es más popular —o se usa más— que <references />. ¿Hay algún motivo técnico o funcional para preferenciar una sobre otra? Gracias por vuestras explicaciones. Carlosmg (discusión) 21:44 7 feb 2019 (UTC)

Carlosmg.dg, creo, listaref usa internamente la etiqueta references para mostrar las referencias. Pero la razón de ser de {{Listaref}} se debe más bien a que posee parámetros para dividir en columnas el listado, especificar el ancho, e incluso el formato de la lista, cosa que <references /> no puede hacer por sí sola. --Giovanni Alfredo Garciliano Díaz ★ diskutujo 22:43 7 feb 2019 (UTC)

Lo bueno de la plantilla, además de que aplica un formato determinado, es que cualquier cambio de estilo en la propia plantilla se propaga a todos sus usos, mientras que la etiqueta necesitaría de una revisión puntual en cada caso. -- Leoncastro (discusión) 23:21 7 feb 2019 (UTC)

Gracias por las explicaciones. @Giovanni Alfredo Garciliano Diaz: Precisamente sobre la configuración del ancho de listaref va el tema que quiero comentar. He detectado que listaref tiene problemas en las versiones móviles cuando se usan los parámetros manuales de columnas, pues cuando se establece cuatro columnas manualmente —por poner un número random—, en una pantalla a 1920x1080 se ve estupendamente, pero en la versión móvil también se distribuye en esas cuatro columnas —lo mismo ocurre con dos, tres, cinco...—, y en este caso por el reducido tamaño de una tablet o móvil el resultado no es que digamos óptimo, pues se obliga a las citas a hacer saltos de línea provocando que no se lean de una manera «normal». Lo que quiero decir es que listaref se ha quedado desfasada en cuanto a diseño, pues en la actualidad no usa un diseño responsive o adaptable. En cambio <references /> si tiene un diseño adaptable cuando activas la opción responsive —<references responsive="" />—, según el número de referencias —creo que sobre diez referencias— automáticamente se establece en un número de columnas determinado por el ancho de la pantalla del dispositivo que estés usando. Por ejemplo, en una resolución de 1920x1080 se muestran tres columnas en mi pantalla de sobremesa, en otra pantalla de menor resolución a dos columnas, pero en mi teléfono móvil se muestra a una columna. Aunque podéis hacer vuestras pruebas de lo que comento con un móvil, podés probar en vuestra pantalla de ordenador con solo agrandar o reducir el ancho de la ventana de vuestro navegador habitual para comprobar los efectos usando la plantilla y con la etiqueta. Ejemplo responsive etiqueta, Ejemplo listaref. Carlosmg (discusión) 01:05 8 feb 2019 (UTC)

Sí Carlosmg.dg, la plantilla tiene sus deficiencias por no estar debidamente optimizada. Sin embargo sigue siendo más efectivo cambiar solamente una plantilla y no miles de páginas. Si te animas puedes modificar la plantilla para que responda al diseño adaptable. -- Leoncastro (discusión) 02:44 8 feb 2019 (UTC)

@Usuario:Leoncastro: Si pudiese lo haría, pero la programación se me queda un poco lejos, y tampoco me atrevo a tocar una plantilla tan utilizada sin saber lo que hago. Pero si debería ser prioritario una adaptación de Listaref a los nuevos tiempos de internet y experiencia de usuario en Wikipedia desde diversos dispositivos. Carlosmg (discusión) 12:56 8 feb 2019 (UTC)

Pues muy bien, Carlosmg.dg, no hay problema: yo pongo una propuesta inicial. Empecemos a debatirla. -- Leoncastro (discusión) 23:07 8 feb 2019 (UTC)

Tech News: 2019-07

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

• You can use the ambox CSS class to show page issues to mobile readers. When you use ambox there are classes you can use.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 February. It will be on non-Wikipedia wikis and some Wikipedias from 13 February. It will be on all wikis from 14 February (calendar).

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 February at 16:00 (UTC). See how to join.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

18:45 11 feb 2019 (UTC)

Wikidata weekly summary #351

Here's your quick overview of what has been happening around Wikidata over the last week.

• Events
  • Past: Linking OpenStreetMap and Wikidata at FOSDEM

• Press, articles, blog posts
  • Paper: Discovering Implicational Knowledge in Wikidata

• Other Noteworthy Stuff
  • There is now an experimental SPARQL service to query Wikidata history

• Did you know?
  • Newest properties:
    • General datatypes: day of regular release, Euler characteristic, has lyrics, maintenance method, CBFC rating, does not have quality
    • External identifiers: Code of Natura 2000/FFH habitat, Douban Author ID, Douban Book ID, Douban Drama ID, Douban Game ID, Douban Music ID, Douban Musician ID, Douban Read Author ID, Douban Read eBook ID, Douban Site Name, Douban Username, Zhihu username, Bilibili bangumi ID, Bilibili tag ID, Bilibili username, Bilibili video ID, Eventa Servo ID, Mtime movie ID, QQ number, Swedish Organization Number, Rock's Backpages artist ID, Rock's Backpages author ID, Rock's Backpages publication ID, Mtime people ID, Democracy Club ID, Hulu movie ID, Hulu series ID, ISA ID, Fuzhou Architecture Heritage ID, DALFAN ID, Den Digitale Byport ID, GameFAQs franchise ID, NMSRCP reference number, Swiss Films ID, CABB player ID, castingvideos ID, Mecklenburg-Vorpommern protected area ID, IEEEXplore author ID, IEEEXplore document ID, Strepsiptera database species ID, Image Archive, Herder-Institut, WBCHSE code, Antarctica NZ Digital Asset Manager, Brentidae of the world species ID, Pacific Coast Architecture Database building ID, Illustrated catalog of Tessaratomidae species ID
  • New property proposals to review:
    • General datatypes: creator name string, Literate population, Illiterate population, designated survivor, stall speed, maintain, Insects (Insecta) of the World ID, solar eclipse type, student organization of
    • External identifiers: BibliotecaVirtualAndalucia authority ID, BIDICAM authority ID, BVPH authority ID, CCBAE ID, identifiant sur l'annuaire du service public, Joan Miró Online Image Bank ID, ISTC No., KSI player ID, Board Game Atlas ID, LSE article ID, JWF Wrestlers Database, Georgian National Filmography ID for Persons, Eliseu Visconti Project ID, Indian census area code (1991), AICTE Permanent ID, German School ID, DOGC ID, DoBIH Number
  • Query examples:
    • Counts of Indian films directed and written by the same person, sorted by film language (source)
    • Sovereign states that have more than one capital city (source)
    • Decreases in sex ratio for mandals of West Godavari district between 2001 and 2011 (source)
    • Counts of articles published in different Indian medical journals, sorted by year/journal (source)
    • Forms to Lexeme ratio per language (source)
    • Airports and railway stations named after fictional people or works of fiction (source)
    • Species of hummingbirds, their genus, and image (source)

• Development
  • Working on the "in more languages" and "all entered languages" parts of the termbox on mobile
  • Working on making undo, revert, edit summaries and more work for Shape Expressions
  • Fixed an error when detecting the same label and description in another Item (phabricator:T194770, thanks Matěj)
  • Making Lemma input on Lexeme pages save your input when you press enter (phabricator:T206140)
  • Making QuickStatements work more easily for other Docker-powered Wikibase instances (phabricator:T205606)
  • Worked more on making Federation work for making Statements on Wikimedia Commons (phabricator:T214557)
  • Working on stripping whitespaces at the beginning and end of Glosses when saving them (phabricator:T212019)
  • Looking into adding more signals to ORES' vandalism detection model so we can detect bad edits more accurately (phabricator:T194737)
  • Preventing a redirect of an Entity onto itself (phabricator:T214775)
  • Fixed an issue with adding sitelinks from Wikimedia Commons (phabricator:T213975)
  • Unified the separators between language and lexical category in different places (phabricator:T201808)

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Suggested and open tasks!
  • 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!

Read the full report · Unsubscribe · Lydia Pintscher (WMDE) 20:32 11 feb 2019 (UTC)

Borrar página de desambiguación

Hola, redirigí una página a una desambiguación, pero ahora necesito borrarla... La página es Teatro João Caetano (Niterói), que es como se debería llamar a la que le puse Teatro João Caetano (que sí debería ser una desambiguación). Pues resulta que hay otro teatro con el mismo nombre en Río (la página todavía no existe en español). ¡Menudo lío! Gracias al que pueda ayudarme. --Pedro Felipe (discusión) 02:44 12 feb 2019 (UTC)

Pedro Felipe, he deshecho la redirección, ya puedes crear Teatro João Caetano como una página de desambigüación. Recuerda colocar la plantilla {{otros usos}} en la otra página. Esteban16 (mensajes) 04:05 12 feb 2019 (UTC)

Mil gracias Esteban16. Saludos, --Pedro Felipe (discusión) 12:03 12 feb 2019 (UTC)

Hilo sobre propuestas técnicas

En el Café de Propuestas he abierto un hilo sobre las propuestas técnicas que preveo realizar en los próximos meses dentro del programa de Rapid Grants de la WMF, y la participación que solicito a la comunidad; dejo constancia aquí para informar debidamente. - José Emilio –jem– Tú dirás... 09:14 12 feb 2019 (UTC)

Ayuda, que el enlace sea opcional

Hola a todos, estoy trabajando en una plantilla de listas en otra wiki, con el siguiente código {{#if: {{{a|}}} | [[{{{a|}}}]] ([[w:{{{a|}}}|WP]]) }} pero quisiera saber. ¿es posible hacer que el enlace local sea opcional dentro de la plantilla? Sé la forma habitual como se hace en las fichas pero quiero hacerlo de estar por ser más práctico para mi. ¿es posible?

Algo parecido se hace al añadir link= en las imágenes

--148.246.181.11 (discusión) 18:51 12 feb 2019 (UTC)

ops, lo siento se cerró la sesión pero por motivos de seguridad prefiero no decir mi cuenta de usuario aquí. Saludos. --148.246.181.11 (discusión) 18:52 12 feb 2019 (UTC)

Todo dependerá bajo qué circunstancias debe omitirse el enlace local. Si deseas que sea una opción configurable manualmente puedes hacer uso de un parámetro adicional. De este modo se puede usar {{#if: {{{a|}}} | {{#ifeq:{{{local|}}}|no||[[{{{a|}}}]]}} ([[w:{{{a|}}}|WP]]) }}, que se llamaría con {{enlace|Ejemplo|local=no}} para omitir el enlace local, o con {{enlace|Ejemplo}} para mostrarlo. Si deseas que se muestre solamente cuando exista la página local —cuidado que esta función conlleva algunos problemas adicionales— puedes hacer {{#if: {{{a|}}} | {{#ifexist:{{{a|}}}|[[{{{a|}}}]]}} ([[w:{{{a|}}}|WP]]) }} y llamarla siempre con {{enlace|Ejemplo}}. También puedes combinar ambos ejemplos, pero si te interesa eso ya te lo dejo como ejercicio. Saludos. -- Leoncastro (discusión) 23:41 12 feb 2019 (UTC)

Grant para mejorar el accesorio ProveIt

¡Hola! Acabo de solicitar un grant rápido para mejorar ProveIt. ProveIt es un gestor de referencias bastante popular aquí y en otras wikis. La idea es hacerlo compatible con el editor visual, el editor de wikitexto nuevo, y otras cosillas. Cualquier idea, propuesta, comentario, pregunta o apoyo es bienvenido en la página del grant. ¡Gracias! Felipe (discusión) 20:41 4 feb 2019 (UTC)

Sophivorus, sugiero crear una página para la herramienta más completa e ilustrativa que la actual, para que sea más entendible y atractiva. De esa forma quizás se pueda extender todavía más su uso. Nota personal: ¡diablos qué poca gente usa aquí la herramienta! -- Leoncastro (discusión) 23:00 4 feb 2019 (UTC)

Me gusta bastante esa herramienta, además de habilitar el uso en el editor visual, yo mejoraría un poco el uso en el editor de código. Por ejemplo al darle a "insertar" blanquee los campos y lleve a la lista de referencias. A veces es confuso y uno no recuerda si añadió o nó la referencia, también al cambiar el tipo de referencia mientras uno edita no se blanqueen los datos de los campos en común que ya hayan sido rellenados.~ℳɑrio - (¿Hablemos?) 13:43 15 feb 2019 (UTC)

¿Que está pasando con la portada?

No se si solo a mi me este pasando o que, tanto en mi cuenta de usuario como leyendo anónimamente, al abrir la portada aparecen códigos que no deberían visualizarse en la portada, además de que colocando en cualquier enlace el puntero y al hacer click me abre un video en youtube. ¿Le pasa a alguien más? Que algún bibliotecario eche vistazo que ocurre con la portada. --Леон Поланко говорит вам и слушает вас 03:38 16 feb 2019 (UTC)

Ya está visualizando normal la portada, pero aún así quisiera saber ¿que pasó? --Леон Поланко говорит вам и слушает вас 04:03 16 feb 2019 (UTC)

@Leonpolanco, por razones obvias no entraré en demasiados detalles; solo indicar que el problema se trataba de un vandalismo que afectaba a algunas plantillas. -- Leoncastro (discusión) 04:19 16 feb 2019 (UTC)

Si Leoncastro, ví a un usuario anónimo que reportó en el tablón un vándalo en plantillas y le preguntó a Marcelo quien atendió el reporte si era posible proteger las plantillas. Por la afectación que en la portada estas plantillas puedan tener, yo si estoy de acuerdo con protección. --Леон Поланко говорит вам и слушает вас 04:22 16 feb 2019 (UTC)

Corrector ortográfico

¿Porque en algunas palabras el corrector solo indica una parte de la palabra marcada con rojo y como resolver la ortografía en estos casos? Para ejemplo y obtenido de Especial:Aleatoria el artículo Azofra (La Rioja), cuya introducción transcribo:

Azofra es un municipio de la comunidad autónoma de La Rioja (España). Noble villa riojana, de orígenes árabes, está situada en el fértil valle del río Tuerto, a 36 Km de Logroño y 8 de Nájera. Es uno de los primeros pueblos riojanos que puede presumir de tener el título de villa, ya que en el año 1168 ya se refieren a Azofra como villa, según se puede leer en los pergaminos guardados en el archivo de la catedral de Calahorra.

Marqué en negritas la palabra según, porque con el corrector ortográfico activado, solo marca con el fondo rojo las tres primeras letras de la palabra, las dos últimas no aparecen con el fondo. ¿Porque ocurre de esta manera? ¿Como resolver en casos similares la ortografía? --Леон Поланко говорит вам и слушает вас 18:46 9 feb 2019 (UTC)

No te preocupes, Leonpolanco, ahí no hay ningún error. Si pasas el cursor por encima del sombreado rojo sin hacer clic aparece un diálogo con la opción sugerida para enmendar lo que se ha escrito si es que estuviera mal (no es el caso). Lo que pasa es que el corrector piensa que ahí «seg» hace referencia a «segundo» y nos recuerda que el símbolo «s» es el único válido oficialmente para esa unidad.

El accesorio funciona también, como puedes ver, con unas letras que no necesariamente forman una palabra completa, y ante la posibilidad de que haya una errata, avisa. Si te interesa, puedes ver (y editar) las incorrecciones que notifica mediante sombreado aquí. Creo que habría que meditar si realmente son útiles algunos de los posibles fallos ortográficos detectados, como el que nos ocupa. Saludos. --Fdo.: Bulsara montañés • 19:33 9 feb 2019 (UTC)

El problema viene de una limitación técnica que aparece al usar palabras con tildes, eñes, diéresis... pero solo en ciertos casos, según expliqué detalladamente en este hilo, que sigue siendo totalmente válido. Sigo teniendo en mente esa y otras muchas mejoras en el corrector y muy probablemente eso entrará en una de mis futuras propuestas técnicas a elaborar con calma. - José Emilio –jem– Tú dirás... 10:54 13 feb 2019 (UTC)

@-jem-, hace tiempo ofrecí una propuesta que además de ampliar la herramienta solucionaba los problemas con las dichosas tildes, eñes y otros caracteres especiales. Lo hablamos incluso en IRC, pero la propuesta no tuvo apoyos suficientes por causa de la ampliación, y aunque te propuse que implementases solamente la solución para las tildes, ahí quedó la cosa. Algo que pudo estar resuelto hace tiempo, ahí sigue. Ya me dirás si la propuesta tiene otros problemas que no hemos hablado, y si se puede resolver el problema a corto plazo. -- Leoncastro (discusión) 14:33 13 feb 2019 (UTC)

Leoncastro, por una parte, como ya comenté en aquel hilo, mantengo muchas ideas para la mejora del corrector y está entre mis futuras propuestas técnicas a presentar, pero requiere un debate amplio y decidir previamente si trataremos de hacerlo a la par con las otras tres Wikipedias que lo usan o no (en cambio, sobre LanguageTool ya me confirmaron que estaba paralizado indefinidamente); me comprometo a que este sea el primero de los debates previos a mis propuestas que deberé lanzar en el Café, una vez recopiladas y ordenadas bien todas las ideas, incluidas las que planteaste en ese hilo (digamos que podría ser entre marzo y abril). Por otra parte, he repasado ese hilo y no acabo de encontrar la solución concreta para el problema de las tildes a la que te refieres, o quizás está en otro sitio o no lo he entendido bien. Si se trata de algo sencillo, por supuesto que puedo implementarlo en breve... por ahora las soluciones que atisbo en mi mente a ese problema son complejas. Ya me comentarás... - José Emilio –jem– Tú dirás... 20:15 16 feb 2019 (UTC)

Sí -jem-, la solución parece sencilla —al menos para el idioma en español, que por algo la herramienta se ubica en tools.wmflabs.org/spellcheck/es/checkArticle.php—, y se trata de reemplazar en la expresión regular de búsqueda el delimitador de palabras \b —que solamente contempla letras ASCII desde la «A» hasta la «Z»— por una expresión más acorde con el alfabeto español como puede ser una expresión excluyente de [a-zá-úüñ] —o incluso [a-zá-úà-ùâ-ûä-üÿýãõñç] si se quieren tener en cuenta alfabetos cercanos como el francés, portugués, italiano, etc.—; y aunque esto no resuelve el 100 % de los casos sí resuelve la gran mayoría. No lo detallé en la propuesta, porque nada tiene que ver solucionar un problema con proponer una variación de la herramienta, y esto simplemente era una solución integrada —ya puestos a cambiar algo, de paso se arregla otra cosa—; pero sí estaba en el código de la herramienta propuesta —ya que eres bibliotecario tendrás acceso a su contenido e historial borrados—. Hablamos estos cambios por IRC, y aunque no te gustaba mucho que no fuese una solución para todos los idiomas, dijiste que lo tomarías en cuenta si LanguageTool no progresaba. El caso es que dos años después de presentarse una posible solución, el problema de «masías» persiste por el simple hecho de no probar esa posible solución. -- Leoncastro (discusión) 23:25 16 feb 2019 (UTC)

Leoncastro, te entiendo, pero efectivamente me parece que no es una solución adecuada; y no solo porque siempre dejaríamos fuera caracteres usados en otros idiomas (y pienso que el corrector podría y debería ampliarse a más de los cuatro actuales), lo que ya me preocupaba entonces en IRC, sino porque además \b es una expresión que no consume caracteres mientras que una alternativa de ese tipo sí consumiría uno a cada lado; esto implicaría que la expresión regular encontrada en el Javascript y que por tanto se marcaría en fondo rojo tendría un carácter más a cada lado de la palabra, y a priori sería poco elegante y quizás algo confuso, salvo que se corrigiera el JS. Además, tengo mis dudas sobre cómo se manejarían los casos exactamente al principio y al final de cada línea y del texto, y las situaciones de solapamiento entre palabras a marcar consecutivas (aquí influye mi rodaje bastante menor en JS que en PHP). La solución definitiva y más completa que veo es el marcado de subcadenas exactas de cualquier longitud, prescindiendo de las limitaciones de las expresiones regulares y permitiendo marcar grupos de palabras, excluir las citas con posibles textos antiguos, etc. Por eso, ante cualquier solución que vaya más allá de un cambio rápido de código sin necesidad de pruebas ni efectos colaterales, prefiero ahorrar tiempo que ahora necesitan mis otras propuestas, y esperar a la reescritura completa que necesita el código y que deberemos debatir. De todas formas podemos seguir comentando posibilidades mientras tanto. - José Emilio –jem– Tú dirás... 14:34 17 feb 2019 (UTC)

Plantilla demografía wikidata

Hola! Veamos. Planteo la situación: en es.wikipedia la población de los municipios españoles se sube anualmente a wikidata vía bot. Este dato es volcado en las fichas ({{ficha de localidad de España}} sin mayores contratiempos. En las introducciones de los artículos, al ser este un dato importante, se suele mencionar también. Hasta este momento se hacía de dos modos:

• Actualizando "a mano" el dato (en cada uno de los más de 8000 municipios españoles: no es plan)
• Mediante la plantilla {{población}} (con un churro como este {{Población|ES|11111}} habitantes ([[Instituto Nacional de Estadística (España)|INE]] {{Población|ES|año}}), que funcionaba especificando el código de cada municipio, en este caso "11111"). Esta plantilla tomaba los datos... de "algún sitio" que, lamentablemente, parece que ya no se va actualizar (este último año los de 2018 ya no se han cargado).

Por esto haría falta una plantilla que hiciera lo que hace la ficha... pero en el texto de la intro. Ya está creada, muy sencilla: {{población-es wd}}. Sin necesidad de datos locales crea un churro con la población más reciente en Wikidata, la palabra "habitantes" y un paréntesis con enlace al INE y el año. Ejemplo.

Haría falta...

• 1) "internacionalizarla" (que sirviera para otros países, indicando el organismo estadístico que toque). Por ejemplo: {{población wd|esp}} (para España y el INE), {{población wd|mex}} (para México y lo que sea), etc. Eso ya no lo sé hacer.
• 2) intentar sustituir con bot los usos de {{población}} por {{población wd}}

¿Alguien podría hacer esto? ¿A alguien le parece mal? el único problema que le veo es que alguien manipule un número en wikidata y le hagamos estar diciendo al INE algo que no dice. Pero 1) los vandalismos en las cifras demográficas no son muy frecuentes 2) no es nada que no pueda pasar ya en wikipedia. strakhov (discusión) 21:34 12 feb 2019 (UTC)

¿Sustituir los usos? Si {{población}} ha quedado obsoleta, creo que la mejor opción es integrarle directamente la función de {{población wd}}, de modo que {{población}} siga funcionando pero obteniendo los datos del mismo modo que {{población wd}}. De ese modo no sería necesario modificar ninguno de los más de dieciocho mil artículos que usan la plantilla, sustituyendo una plantilla obsoleta por otra equivalente. -- Leoncastro (discusión) 23:48 12 feb 2019 (UTC)

Por cierto, lo que sería necesario modificar realmente es Módulo:Población/ES, para que en lugar de tomar los datos desde su código (desactualizado), lo tomase desde Wikidata o desde algún otro volcado de datos. -- Leoncastro (discusión) 23:55 12 feb 2019 (UTC)

Bueno, es otra forma desde luego. En tal caso habría que reprogramar Módulo:Población/ES para que cuando en el primer parámetro de {{población}} hubiera un ES y en el segundo un número, mostrara esto {{Propiedad|P1082|rango_mayor=sí|prioridad=sí|uno=sí}}, y que cuando hubiera en el primer parámetro un ES y en el segundo la cadena de caracteres año mostrara esto otro: {{Propiedad|P1082|calificador=P585|rango_mayor=sí|prioridad=sí|uno=sí|enlace=no}}. Ni idea cómo se hace tampoco. Esto tiene la ventaja de no requerir ninguna sustitución masiva, y la desventaja de dejar toneladas de código muerto (¿o código inalcanzable?) inservible en los artículos (el código municipal), pero visto lo visto con otros códigos muertos recientes (fichas, distancias) no parece que esto fuera a suponer un gran problema. strakhov (discusión) 00:14 13 feb 2019 (UTC)

Otra ventaja quedarnos con el código inalcanzable es que si algo se estropea en wikidata con la población (se dejara de almacenar allí por lo que sea), podríamos restaurar el módulo antiguo y volver a tener datos, atrasados, pero datos a fin de cuentas... de 2017 (al fin me entero de dónde salían los datos). strakhov (discusión) 00:23 13 feb 2019 (UTC)

@Strakhov, el problema es que para sustituir directamente una plantilla por otra, ambas deberían ser equivalentes en su lugar de uso, y de momento no lo son. Básicamente porque {{Población-es wd}} no tiene en cuenta parámetros, ofreciendo los datos de Wikidata almacenados para el propio artículo. Esto impide que se pueda usar, por ejemplo, en la supuesta frase de la [[provincia de León]] cuenta con {{población|ES|24}} habitantes, siendo sus ciudades más pobladas [[León]] (con {{población|ES|24089}} habitantes) y [[Ponferrada]] (con {{población|ES|24115}} habitantes): «la provincia de León cuenta con 468 316 habitantes, siendo sus ciudades más pobladas León (con 125 317 habitantes) y Ponferrada (con 65 788 habitantes)». Es por eso que la plantilla necesita los códigos del censo. -- Leoncastro (discusión) 00:33 13 feb 2019 (UTC)

Bueno, en tal caso... lo que haría falta es...

1) sencillamente seguir actualizando anual y localmente nuestro módulo (no se está haciendo). Y no cambiar nada.

2) tener disponibles dos plantillas. Una que vuelque la información a pelo de wikidata desde el item principal ({{población-es wd}} por ejemplo, o algo del estilo). Y que la actual "de sintaxis más libre" se las arregle como pueda para actualizarse.

3) Sustituir con bot los códigos INE de {{población}} por los Q's de wikidata correspondientes y reformar la plantilla (desde la ignorancia, me temo que será más fácil invocar la población de wikidata de un "tercer item" directamente con su "Q" a hacerlo indirectamente con el código INE, ojalá me equivoque. Existe esto, pero no sé si será implantable, también se puede consultar vía query, pero...). strakhov (discusión) 00:54 13 feb 2019 (UTC) ¿quizás con una relación local de códigos INE y Q's de wikidata se podría hacer? (al fin y al cabo ahora el módulo es una inmensa lista de códigos INE y su correspondiente población)

Una cuarta opción (variante de la tercera) sería implementar como tabla interna en el módulo lo de sustituir el n.º de INE por el correspondiente Q de Wikidata, haciendo que fuera innecesaria la sustitución masiva con bot de esos parámetros. ¿Quien sube a Wikidata automáticamente los datos cada año? Esa persona ya tendrá la tabla de equivalencias INE a Q. -- Leoncastro (discusión) 01:09 13 feb 2019 (UTC)

En Wikidata el bot de @Kizar:, creo. En wikipedia parece que las últimas actualizaciones eran vía @Jospint:. Estoy empezando a pensar que seguramente lo más sencillo sea 1). En su momento estuve estudiando algo similar (para importar la población de entidades no municipales con QuickStatements) y no parecía tan difícil jugando un poco con Excel sacar la lista, desde luego la de "Q's vs INE" es trivial vía Query y la de "INE vs población" te la puedes descargar (aunque habrá que cocinar el formato), lo que era marginalmente más complejo (y computationally expensive con la inmensa lista) era correlacionar los INE con los Q para cargar los datos a Wikidata pero hasta a mí me salió (al final será más complicado y me estaré pasando de listo, suele pasarme). strakhov (discusión) 01:24 13 feb 2019 (UTC)

Efectivamente, el tema de la inserción de datos variables directamente en el texto de los artículos, fuera de las fichas, necesitaba ser abordado desde la llegada de Wikidata y no tiene una solución sencilla; por eso habría que analizarlo globalmente desde el principio. Estamos hablando no solo de las poblaciones de todas las entidades nacionales y subnacionales, sino de cualquier otro dato variable que esté recogido en Wikidata. Siempre he temido que insertar cualquier tipo de plantillas en el cuerpo del texto podía ser considerado por algunos poco amigable para los editores (sobre todo los menos experimentados) y que cabía incluso la opción de prohibir completamente insertar datos variables fuera de las fichas, aunque entiendo que es muy difícil conseguirlo en la práctica. Pero bien, asumiendo que vamos a incluir los datos, desde luego debería ser con una plantilla que lea Wikidata (nunca duplicando el trabajo que ya se hace allí) y procurando que sea lo más legible posible... ciertamente apoyo que se siga llamando {{Población}}, por legibilidad y por evitar el cambio bótico masivo, convirtiendo el código de la actual en un switch que invoque a las propiedades correspondientes de Wikidata según el país, a partir del trabajo de Strakhov; pero tenemos que pensar si nos parece bien empezar a crear plantillas similares para otros datos importados desde Wikidata. Y por otro lado, lo de necesitar invocar los datos de otros artículos/elementos, con la consiguiente necesidad de manejar los Q y «complicarnos la existencia» (de nuevo, no pienso solo en el caso de la población) me parece más discutible. Creo que en muchos casos será prescindible, y cuando no lo sea, sería preferible admitir solo el uso de {{Wikidata list}}, al menos mientras Wikidata no proporcione otra solución para generar listas; actualmente solo se usa en 2 artículos y 22 anexos, pero podemos pensar en extender su uso. En todo caso, hay que reflexionarlo en profundidad y llegar a un consenso claro antes de lanzar a los bots... - José Emilio –jem– Tú dirás... 10:54 13 feb 2019 (UTC)

Veamos. En primer lugar, asumo que la población actual es un dato que debería figurar en todas (y ya figura en muchas) las introducciones de todos los artículos de municipios de España (y del mundo también debería, mas me centro ahorita en la piel de toro), esté en la ficha o no. Si no lo incluimos "nosotros", lo terminará haciendo "la gente" (no se pueden poner puertas al campo). Aceptando ese supuesto lo podemos actualizar a mano en cada uno de los 8124 municipios o abordar algún tipo de actualización global automática. No tengo dudas de que es mejor lo segundo. ¿Otros datos que pudieran merecer transclusión desde terceras páginas fuera de las fichas? No se me ocurre ninguno tan vital, seguro que los habrá.

En segundo lugar, no si será poco amigable la plantilla. Hasta hora, he visto pocas quejas sobre la amigabilidad de {{población}} (que tiene parámetros varios), por lo que la de algo más simple en plan {{población wikidata}} (sin nada que rellenar) tendría, supongo, aún menos detractores. No creo que sea menos amigable que usar {{esd}}, {{siglo}}, {{cita publicación}} o cualquier plantilla en el texto de un artículo. El problema aparece cuando «nos» "retrasamos" en actualizar los datos, momento en que las masas se ponen nerviosas y comienzan a sustituir la dichosa plantilla por el número "manual" (estropeándolo para el año siguiente). Lo que lleva a...

...¿dónde es mejor actualizarlo? Después de haber descubierto las tripas del módulo Módulo:Población/ES, corregidme si me equivoco... ¿es prácticamente igual de fácil (o incluso más) renovar los datos en wikipedia que hacerlo en wikidata? Parto de la idea de que nada acá es obligatorio y que los datos se actualizarán cuando alguien que sepa... decida hacerlo, por lo que no creo que deban ser excluyentes ambos métodos (¿se podría instalar algún tipo de "switch" para aprovechar en {{población}} los datos de wikidata o los locales en función de cuáles estén cargados? (no digo que sea lo ideal a largo plazo, pero mientras funcionemos tan a tirones, lo mismo ni tan mal). Si alguien decide botear [o quickstatementear] el excel del INE a wikidata adelante (lo podrán aprovechar también otras wikipedias), si quiere pegar aquí la ristra, también (será más limpio con el tema de las licencias y hasta lo podríamos "semiproteger" o "fullprotect"). Lo ideal sería que una y otra tarea estuvieran descritas a prueba de tontos en algún rincón, en plan receta de cocina, para que cualquier imbécil (como servidor) la lleve a cabo si los enteraos que lo hacían antes ya no están.

Respecto a las invocaciones de terceros elementos... a título personal puedo vivir sin ellas (las he debido usar muy poquito, sobre todo en el espacio principal), pero tampoco me pondría muy plasta en eliminarlas (en especial sin tener idea de cuán generalizado es su uso). En cuanto a {{wikidata list}} ... a esa plantilla siempre la he visto más potencial para esas listas largas y un poco "arbitrarias" que no nos gustan demasiado (anexos de nacidos en un lugar, anexos de enterrados en un cementerio) o de monumentos o cosas así (en general, siempre en el espacio Anexo:), con un poco de regulación normativa (longitud máxima incluida), claro está. Para usarla en artículos tengo más dudas, aunque solo sea por evitar al personal las muy frecuentes actualizaciones del bot que en la práctica no cambian apenas nada (tendríamos los historiales de los artículos floodeados por las ediciones de ListeriaBot, en un anexo me parece menos pernicioso este efecto). Para anexos provinciales de municipios y mostrar la población sin dos centenares de invocaciones a terceros... pues es una posibilidad, sí. strakhov (discusión) 15:50 13 feb 2019 (UTC)

 A favor de tomar los datos de poblacion de wikidata y de generar plantillas para usar en los textos de los artículos. Creo que para esto último hay que discutirlo bien, tal vez haciendo alguna votación formal antes de usarlo masivamente. Se me ocurren varios usos (equipo actual de deportista, político elegido a cargo, presidentes de organizaciones, etc), en fin todos los datos muy volátiles los traería de wikidata. En cuanto a poder construir frases como «la provincia de León cuenta con 468 316 habitantes, siendo sus ciudades más pobladas León (con 125 317 habitantes) y Ponferrada (con 65 788 habitantes)», se puede hacer desde wikidata (es el acceso arbitrario), aunque es más pesado traer datos indicando un Q distinto que el enlazado en el artículo actual. Para el PR:NMSF-AR construí un módulo lua que lo hace ("inspirado" en [2]) y funciona bien (y se cachea por lo que no es tan pesado tampoco).

Yo puedo ayudar con los datos de municipios de Argentina, y al módulo población lo haría lo más genérico posible, si se pude traer la información de las referencias desde wikidata, mejor. Saludos, Juanman (discusión) 16:00 17 feb 2019 (UTC)

Wikidata weekly summary #352

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • Open request for adminship: NewDataB
  • New request for comments: semi-protection to prevent vandalism on most used Items, Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)

• Events
  • February 19th: Wikidata meetup in London - Facebook event
  • February 21st to 24th: International Mother Language Day edit-a-thon
  • February 23rd: editathon about Parliament of Ghana in Accra - Registration
  • March 28th: GLAM & Wikidata day in Switzerland (registration running until March 18th)

• Press, articles, blog posts
  • Let’s Tango: Computational Musicology Using Wikidata, MusicBrainz and the Wolfram Language, by Toni Schindler

• Other Noteworthy Stuff
  • Got some time? Add QIDs to the tools on Edit items, Query data, Enhance user interface, Visualize data, Lexicographical data, For programmers and List of properties. If some tools don't have their own Items, feel free to create them.
  • Hardware issues at Toolforge and CloudVPS affect lots of tools and coincide with changes in the statement stats dynamics
  • WikibaseCirrusSearch will become a Mediawiki extension
  • You can still help Shani Evenstein with her research: Wikidata as a Learning Platform

• Did you know?
  • Newest properties:
    • General datatypes: drag coefficient, illiterate population, literate population, non-free artwork image URL, taxon author citation, total goals in career, stall speed
    • External identifiers: Enciclopedia delle donne ID, Joan Miró Online Image Bank ID, BIDICAM authority ID, Board Game Atlas ID, BVPH authority ID, CCBAE publication ID, ISTC No., KSI player ID, Biblioteca Virtual Andalucía authority ID, Georgian National Filmography ID for Persons, JWF Wrestlers Database person ID, Indian census area code (1991), Lithuanian Sport Encyclopedia (LSE) article ID, Eliseu Visconti Project ID, UN/CEFACT common code
  • New property proposals to review:
    • General datatypes: ScaleNet ID, Lokalhistoriewiki article, Identifiant itch.io, approach angle, departure angle, ride height, type of front suspensions, type of rear suspensions, Football Money League rank, is model of, constraint clarification, has phenotype, observed in, replacement property, evidenční číslo domu, Stack Exchange site
    • External identifiers: WhoSampled artist, äriregister, ISO 639-3 Change Request ID, Queerly Represent Me identifier, V.League player ID, Martindale-Hubbell profile, Google Play Movies & TV id, Fondation Maeght ID, identifiant d'un jeu de données sur data.gouv.fr, BHL part ID, ETS Designated Institution code, Gateway to Research Project ID, Yandex.Music label ID, Yandex.Music genre ID
  • Query examples:
    • Bubble chart of Indian universities with the most people ever employed by them (source)
    • Graph of shared borders between certain West Bengal community development blocks (source)
    • Tree map of ambassadors to India (source)
    • Fictional swords (source)
    • Taxa named after women scientists (source)
    • Timeline of red pandas (source)

• Development
  • Improve the tools dropdown on query.wikidata.org, which now links Tools categories and the Toolforge (phabricator:T214577)
  • Implement the diff view for Schemas (phabricator:T214396, phabricator:T215514)
  • Implement undo for Schemas (phabricator:T214914)
  • Prevent redirecting an entity to itself (phabricator:T214775)
  • Make pressing enter when editing a lemma save the lemma (phabricator:T206140)
  • Strip whitespace around sense glosses (phabricator:T212019)
  • Create LilyPond datatype (phabricator:T215284)
  • More work to get the new version of the termbox readable on mobile

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
  • Suggested and open tasks!
  • 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!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:36 18 feb 2019 (UTC)

Tech News: 2019-08

Las últimas noticias de tecnología de la comunidad técnica de Wikimedia. Coméntale a otros usuarios acerca de estos cambios. Algunos cambios no te afectarán. Existen traducciones disponibles.

Cambios recientes

• Cuando agradezcas a alguien en la versión web para móviles, tendrás dos segundos para cancelar la acción. Esto es en caso que accidentalmente presiones el botón. [3]

Cambios de esta semana

• La nueva versión de MediaWiki estará disponible en las wikis de prueba y Mediawiki.org desde 19 febrero. Se habilitará en las wikis que no sean Wikipedia y en algunas Wikipedias el 20 febrero. Se disponibilizará en todas las wikis desde el 21 febrero (calendario).

Reuniones

• Puedes unirte a la reunión de asesoramiento técnico en el IRC. Durante la reunión, los desarrolladores voluntarios pueden pedir consejo. La reunión será el 20 febrero a las 16:00 (UTC). Mira cómo unirte.

Cambios futuros

• Existe una propuesta para añadir los enlaces en rojo a los resultados de búsqueda móvil si no existe una página con ese nombre. Es así cómo está funcionando en la versión de escritorio. Puedes dejarnos comentarios acerca de esta propuesta. [4]

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.

23:13 18 feb 2019 (UTC)

Corrector ortográfico

¿Porque en algunas palabras el corrector solo indica una parte de la palabra marcada con rojo y como resolver la ortografía en estos casos? Para ejemplo y obtenido de Especial:Aleatoria el artículo Azofra (La Rioja), cuya introducción transcribo:

Azofra es un municipio de la comunidad autónoma de La Rioja (España). Noble villa riojana, de orígenes árabes, está situada en el fértil valle del río Tuerto, a 36 Km de Logroño y 8 de Nájera. Es uno de los primeros pueblos riojanos que puede presumir de tener el título de villa, ya que en el año 1168 ya se refieren a Azofra como villa, según se puede leer en los pergaminos guardados en el archivo de la catedral de Calahorra.

Marqué en negritas la palabra según, porque con el corrector ortográfico activado, solo marca con el fondo rojo las tres primeras letras de la palabra, las dos últimas no aparecen con el fondo. ¿Porque ocurre de esta manera? ¿Como resolver en casos similares la ortografía? --Леон Поланко говорит вам и слушает вас 18:46 9 feb 2019 (UTC)

No te preocupes, Leonpolanco, ahí no hay ningún error. Si pasas el cursor por encima del sombreado rojo sin hacer clic aparece un diálogo con la opción sugerida para enmendar lo que se ha escrito si es que estuviera mal (no es el caso). Lo que pasa es que el corrector piensa que ahí «seg» hace referencia a «segundo» y nos recuerda que el símbolo «s» es el único válido oficialmente para esa unidad.

El accesorio funciona también, como puedes ver, con unas letras que no necesariamente forman una palabra completa, y ante la posibilidad de que haya una errata, avisa. Si te interesa, puedes ver (y editar) las incorrecciones que notifica mediante sombreado aquí. Creo que habría que meditar si realmente son útiles algunos de los posibles fallos ortográficos detectados, como el que nos ocupa. Saludos. --Fdo.: Bulsara montañés • 19:33 9 feb 2019 (UTC)

El problema viene de una limitación técnica que aparece al usar palabras con tildes, eñes, diéresis... pero solo en ciertos casos, según expliqué detalladamente en este hilo, que sigue siendo totalmente válido. Sigo teniendo en mente esa y otras muchas mejoras en el corrector y muy probablemente eso entrará en una de mis futuras propuestas técnicas a elaborar con calma. - José Emilio –jem– Tú dirás... 10:54 13 feb 2019 (UTC)

@-jem-, hace tiempo ofrecí una propuesta que además de ampliar la herramienta solucionaba los problemas con las dichosas tildes, eñes y otros caracteres especiales. Lo hablamos incluso en IRC, pero la propuesta no tuvo apoyos suficientes por causa de la ampliación, y aunque te propuse que implementases solamente la solución para las tildes, ahí quedó la cosa. Algo que pudo estar resuelto hace tiempo, ahí sigue. Ya me dirás si la propuesta tiene otros problemas que no hemos hablado, y si se puede resolver el problema a corto plazo. -- Leoncastro (discusión) 14:33 13 feb 2019 (UTC)

Leoncastro, por una parte, como ya comenté en aquel hilo, mantengo muchas ideas para la mejora del corrector y está entre mis futuras propuestas técnicas a presentar, pero requiere un debate amplio y decidir previamente si trataremos de hacerlo a la par con las otras tres Wikipedias que lo usan o no (en cambio, sobre LanguageTool ya me confirmaron que estaba paralizado indefinidamente); me comprometo a que este sea el primero de los debates previos a mis propuestas que deberé lanzar en el Café, una vez recopiladas y ordenadas bien todas las ideas, incluidas las que planteaste en ese hilo (digamos que podría ser entre marzo y abril). Por otra parte, he repasado ese hilo y no acabo de encontrar la solución concreta para el problema de las tildes a la que te refieres, o quizás está en otro sitio o no lo he entendido bien. Si se trata de algo sencillo, por supuesto que puedo implementarlo en breve... por ahora las soluciones que atisbo en mi mente a ese problema son complejas. Ya me comentarás... - José Emilio –jem– Tú dirás... 20:15 16 feb 2019 (UTC)

Sí -jem-, la solución parece sencilla —al menos para el idioma en español, que por algo la herramienta se ubica en tools.wmflabs.org/spellcheck/es/checkArticle.php—, y se trata de reemplazar en la expresión regular de búsqueda el delimitador de palabras \b —que solamente contempla letras ASCII desde la «A» hasta la «Z»— por una expresión más acorde con el alfabeto español como puede ser una expresión excluyente de [a-zá-úüñ] —o incluso [a-zá-úà-ùâ-ûä-üÿýãõñç] si se quieren tener en cuenta alfabetos cercanos como el francés, portugués, italiano, etc.—; y aunque esto no resuelve el 100 % de los casos sí resuelve la gran mayoría. No lo detallé en la propuesta, porque nada tiene que ver solucionar un problema con proponer una variación de la herramienta, y esto simplemente era una solución integrada —ya puestos a cambiar algo, de paso se arregla otra cosa—; pero sí estaba en el código de la herramienta propuesta —ya que eres bibliotecario tendrás acceso a su contenido e historial borrados—. Hablamos estos cambios por IRC, y aunque no te gustaba mucho que no fuese una solución para todos los idiomas, dijiste que lo tomarías en cuenta si LanguageTool no progresaba. El caso es que dos años después de presentarse una posible solución, el problema de «masías» persiste por el simple hecho de no probar esa posible solución. -- Leoncastro (discusión) 23:25 16 feb 2019 (UTC)

Leoncastro, te entiendo, pero efectivamente me parece que no es una solución adecuada; y no solo porque siempre dejaríamos fuera caracteres usados en otros idiomas (y pienso que el corrector podría y debería ampliarse a más de los cuatro actuales), lo que ya me preocupaba entonces en IRC, sino porque además \b es una expresión que no consume caracteres mientras que una alternativa de ese tipo sí consumiría uno a cada lado; esto implicaría que la expresión regular encontrada en el Javascript y que por tanto se marcaría en fondo rojo tendría un carácter más a cada lado de la palabra, y a priori sería poco elegante y quizás algo confuso, salvo que se corrigiera el JS. Además, tengo mis dudas sobre cómo se manejarían los casos exactamente al principio y al final de cada línea y del texto, y las situaciones de solapamiento entre palabras a marcar consecutivas (aquí influye mi rodaje bastante menor en JS que en PHP). La solución definitiva y más completa que veo es el marcado de subcadenas exactas de cualquier longitud, prescindiendo de las limitaciones de las expresiones regulares y permitiendo marcar grupos de palabras, excluir las citas con posibles textos antiguos, etc. Por eso, ante cualquier solución que vaya más allá de un cambio rápido de código sin necesidad de pruebas ni efectos colaterales, prefiero ahorrar tiempo que ahora necesitan mis otras propuestas, y esperar a la reescritura completa que necesita el código y que deberemos debatir. De todas formas podemos seguir comentando posibilidades mientras tanto. - José Emilio –jem– Tú dirás... 14:34 17 feb 2019 (UTC)

Plantilla demografía wikidata

Hola! Veamos. Planteo la situación: en es.wikipedia la población de los municipios españoles se sube anualmente a wikidata vía bot. Este dato es volcado en las fichas ({{ficha de localidad de España}} sin mayores contratiempos. En las introducciones de los artículos, al ser este un dato importante, se suele mencionar también. Hasta este momento se hacía de dos modos:

• Actualizando "a mano" el dato (en cada uno de los más de 8000 municipios españoles: no es plan)
• Mediante la plantilla {{población}} (con un churro como este {{Población|ES|11111}} habitantes ([[Instituto Nacional de Estadística (España)|INE]] {{Población|ES|año}}), que funcionaba especificando el código de cada municipio, en este caso "11111"). Esta plantilla tomaba los datos... de "algún sitio" que, lamentablemente, parece que ya no se va actualizar (este último año los de 2018 ya no se han cargado).

Por esto haría falta una plantilla que hiciera lo que hace la ficha... pero en el texto de la intro. Ya está creada, muy sencilla: {{población-es wd}}. Sin necesidad de datos locales crea un churro con la población más reciente en Wikidata, la palabra "habitantes" y un paréntesis con enlace al INE y el año. Ejemplo.

Haría falta...

• 1) "internacionalizarla" (que sirviera para otros países, indicando el organismo estadístico que toque). Por ejemplo: {{población wd|esp}} (para España y el INE), {{población wd|mex}} (para México y lo que sea), etc. Eso ya no lo sé hacer.
• 2) intentar sustituir con bot los usos de {{población}} por {{población wd}}

¿Alguien podría hacer esto? ¿A alguien le parece mal? el único problema que le veo es que alguien manipule un número en wikidata y le hagamos estar diciendo al INE algo que no dice. Pero 1) los vandalismos en las cifras demográficas no son muy frecuentes 2) no es nada que no pueda pasar ya en wikipedia. strakhov (discusión) 21:34 12 feb 2019 (UTC)

¿Sustituir los usos? Si {{población}} ha quedado obsoleta, creo que la mejor opción es integrarle directamente la función de {{población wd}}, de modo que {{población}} siga funcionando pero obteniendo los datos del mismo modo que {{población wd}}. De ese modo no sería necesario modificar ninguno de los más de dieciocho mil artículos que usan la plantilla, sustituyendo una plantilla obsoleta por otra equivalente. -- Leoncastro (discusión) 23:48 12 feb 2019 (UTC)

Por cierto, lo que sería necesario modificar realmente es Módulo:Población/ES, para que en lugar de tomar los datos desde su código (desactualizado), lo tomase desde Wikidata o desde algún otro volcado de datos. -- Leoncastro (discusión) 23:55 12 feb 2019 (UTC)

Bueno, es otra forma desde luego. En tal caso habría que reprogramar Módulo:Población/ES para que cuando en el primer parámetro de {{población}} hubiera un ES y en el segundo un número, mostrara esto {{Propiedad|P1082|rango_mayor=sí|prioridad=sí|uno=sí}}, y que cuando hubiera en el primer parámetro un ES y en el segundo la cadena de caracteres año mostrara esto otro: {{Propiedad|P1082|calificador=P585|rango_mayor=sí|prioridad=sí|uno=sí|enlace=no}}. Ni idea cómo se hace tampoco. Esto tiene la ventaja de no requerir ninguna sustitución masiva, y la desventaja de dejar toneladas de código muerto (¿o código inalcanzable?) inservible en los artículos (el código municipal), pero visto lo visto con otros códigos muertos recientes (fichas, distancias) no parece que esto fuera a suponer un gran problema. strakhov (discusión) 00:14 13 feb 2019 (UTC)

Otra ventaja quedarnos con el código inalcanzable es que si algo se estropea en wikidata con la población (se dejara de almacenar allí por lo que sea), podríamos restaurar el módulo antiguo y volver a tener datos, atrasados, pero datos a fin de cuentas... de 2017 (al fin me entero de dónde salían los datos). strakhov (discusión) 00:23 13 feb 2019 (UTC)

@Strakhov, el problema es que para sustituir directamente una plantilla por otra, ambas deberían ser equivalentes en su lugar de uso, y de momento no lo son. Básicamente porque {{Población-es wd}} no tiene en cuenta parámetros, ofreciendo los datos de Wikidata almacenados para el propio artículo. Esto impide que se pueda usar, por ejemplo, en la supuesta frase de la [[provincia de León]] cuenta con {{población|ES|24}} habitantes, siendo sus ciudades más pobladas [[León]] (con {{población|ES|24089}} habitantes) y [[Ponferrada]] (con {{población|ES|24115}} habitantes): «la provincia de León cuenta con 468 316 habitantes, siendo sus ciudades más pobladas León (con 125 317 habitantes) y Ponferrada (con 65 788 habitantes)». Es por eso que la plantilla necesita los códigos del censo. -- Leoncastro (discusión) 00:33 13 feb 2019 (UTC)

Bueno, en tal caso... lo que haría falta es...

1) sencillamente seguir actualizando anual y localmente nuestro módulo (no se está haciendo). Y no cambiar nada.

2) tener disponibles dos plantillas. Una que vuelque la información a pelo de wikidata desde el item principal ({{población-es wd}} por ejemplo, o algo del estilo). Y que la actual "de sintaxis más libre" se las arregle como pueda para actualizarse.

3) Sustituir con bot los códigos INE de {{población}} por los Q's de wikidata correspondientes y reformar la plantilla (desde la ignorancia, me temo que será más fácil invocar la población de wikidata de un "tercer item" directamente con su "Q" a hacerlo indirectamente con el código INE, ojalá me equivoque. Existe esto, pero no sé si será implantable, también se puede consultar vía query, pero...). strakhov (discusión) 00:54 13 feb 2019 (UTC) ¿quizás con una relación local de códigos INE y Q's de wikidata se podría hacer? (al fin y al cabo ahora el módulo es una inmensa lista de códigos INE y su correspondiente población)

Una cuarta opción (variante de la tercera) sería implementar como tabla interna en el módulo lo de sustituir el n.º de INE por el correspondiente Q de Wikidata, haciendo que fuera innecesaria la sustitución masiva con bot de esos parámetros. ¿Quien sube a Wikidata automáticamente los datos cada año? Esa persona ya tendrá la tabla de equivalencias INE a Q. -- Leoncastro (discusión) 01:09 13 feb 2019 (UTC)

En Wikidata el bot de @Kizar:, creo. En wikipedia parece que las últimas actualizaciones eran vía @Jospint:. Estoy empezando a pensar que seguramente lo más sencillo sea 1). En su momento estuve estudiando algo similar (para importar la población de entidades no municipales con QuickStatements) y no parecía tan difícil jugando un poco con Excel sacar la lista, desde luego la de "Q's vs INE" es trivial vía Query y la de "INE vs población" te la puedes descargar (aunque habrá que cocinar el formato), lo que era marginalmente más complejo (y computationally expensive con la inmensa lista) era correlacionar los INE con los Q para cargar los datos a Wikidata pero hasta a mí me salió (al final será más complicado y me estaré pasando de listo, suele pasarme). strakhov (discusión) 01:24 13 feb 2019 (UTC)

Efectivamente, el tema de la inserción de datos variables directamente en el texto de los artículos, fuera de las fichas, necesitaba ser abordado desde la llegada de Wikidata y no tiene una solución sencilla; por eso habría que analizarlo globalmente desde el principio. Estamos hablando no solo de las poblaciones de todas las entidades nacionales y subnacionales, sino de cualquier otro dato variable que esté recogido en Wikidata. Siempre he temido que insertar cualquier tipo de plantillas en el cuerpo del texto podía ser considerado por algunos poco amigable para los editores (sobre todo los menos experimentados) y que cabía incluso la opción de prohibir completamente insertar datos variables fuera de las fichas, aunque entiendo que es muy difícil conseguirlo en la práctica. Pero bien, asumiendo que vamos a incluir los datos, desde luego debería ser con una plantilla que lea Wikidata (nunca duplicando el trabajo que ya se hace allí) y procurando que sea lo más legible posible... ciertamente apoyo que se siga llamando {{Población}}, por legibilidad y por evitar el cambio bótico masivo, convirtiendo el código de la actual en un switch que invoque a las propiedades correspondientes de Wikidata según el país, a partir del trabajo de Strakhov; pero tenemos que pensar si nos parece bien empezar a crear plantillas similares para otros datos importados desde Wikidata. Y por otro lado, lo de necesitar invocar los datos de otros artículos/elementos, con la consiguiente necesidad de manejar los Q y «complicarnos la existencia» (de nuevo, no pienso solo en el caso de la población) me parece más discutible. Creo que en muchos casos será prescindible, y cuando no lo sea, sería preferible admitir solo el uso de {{Wikidata list}}, al menos mientras Wikidata no proporcione otra solución para generar listas; actualmente solo se usa en 2 artículos y 22 anexos, pero podemos pensar en extender su uso. En todo caso, hay que reflexionarlo en profundidad y llegar a un consenso claro antes de lanzar a los bots... - José Emilio –jem– Tú dirás... 10:54 13 feb 2019 (UTC)

Veamos. En primer lugar, asumo que la población actual es un dato que debería figurar en todas (y ya figura en muchas) las introducciones de todos los artículos de municipios de España (y del mundo también debería, mas me centro ahorita en la piel de toro), esté en la ficha o no. Si no lo incluimos "nosotros", lo terminará haciendo "la gente" (no se pueden poner puertas al campo). Aceptando ese supuesto lo podemos actualizar a mano en cada uno de los 8124 municipios o abordar algún tipo de actualización global automática. No tengo dudas de que es mejor lo segundo. ¿Otros datos que pudieran merecer transclusión desde terceras páginas fuera de las fichas? No se me ocurre ninguno tan vital, seguro que los habrá.

En segundo lugar, no si será poco amigable la plantilla. Hasta hora, he visto pocas quejas sobre la amigabilidad de {{población}} (que tiene parámetros varios), por lo que la de algo más simple en plan {{población wikidata}} (sin nada que rellenar) tendría, supongo, aún menos detractores. No creo que sea menos amigable que usar {{esd}}, {{siglo}}, {{cita publicación}} o cualquier plantilla en el texto de un artículo. El problema aparece cuando «nos» "retrasamos" en actualizar los datos, momento en que las masas se ponen nerviosas y comienzan a sustituir la dichosa plantilla por el número "manual" (estropeándolo para el año siguiente). Lo que lleva a...

...¿dónde es mejor actualizarlo? Después de haber descubierto las tripas del módulo Módulo:Población/ES, corregidme si me equivoco... ¿es prácticamente igual de fácil (o incluso más) renovar los datos en wikipedia que hacerlo en wikidata? Parto de la idea de que nada acá es obligatorio y que los datos se actualizarán cuando alguien que sepa... decida hacerlo, por lo que no creo que deban ser excluyentes ambos métodos (¿se podría instalar algún tipo de "switch" para aprovechar en {{población}} los datos de wikidata o los locales en función de cuáles estén cargados? (no digo que sea lo ideal a largo plazo, pero mientras funcionemos tan a tirones, lo mismo ni tan mal). Si alguien decide botear [o quickstatementear] el excel del INE a wikidata adelante (lo podrán aprovechar también otras wikipedias), si quiere pegar aquí la ristra, también (será más limpio con el tema de las licencias y hasta lo podríamos "semiproteger" o "fullprotect"). Lo ideal sería que una y otra tarea estuvieran descritas a prueba de tontos en algún rincón, en plan receta de cocina, para que cualquier imbécil (como servidor) la lleve a cabo si los enteraos que lo hacían antes ya no están.

Respecto a las invocaciones de terceros elementos... a título personal puedo vivir sin ellas (las he debido usar muy poquito, sobre todo en el espacio principal), pero tampoco me pondría muy plasta en eliminarlas (en especial sin tener idea de cuán generalizado es su uso). En cuanto a {{wikidata list}} ... a esa plantilla siempre la he visto más potencial para esas listas largas y un poco "arbitrarias" que no nos gustan demasiado (anexos de nacidos en un lugar, anexos de enterrados en un cementerio) o de monumentos o cosas así (en general, siempre en el espacio Anexo:), con un poco de regulación normativa (longitud máxima incluida), claro está. Para usarla en artículos tengo más dudas, aunque solo sea por evitar al personal las muy frecuentes actualizaciones del bot que en la práctica no cambian apenas nada (tendríamos los historiales de los artículos floodeados por las ediciones de ListeriaBot, en un anexo me parece menos pernicioso este efecto). Para anexos provinciales de municipios y mostrar la población sin dos centenares de invocaciones a terceros... pues es una posibilidad, sí. strakhov (discusión) 15:50 13 feb 2019 (UTC)

 A favor de tomar los datos de poblacion de wikidata y de generar plantillas para usar en los textos de los artículos. Creo que para esto último hay que discutirlo bien, tal vez haciendo alguna votación formal antes de usarlo masivamente. Se me ocurren varios usos (equipo actual de deportista, político elegido a cargo, presidentes de organizaciones, etc), en fin todos los datos muy volátiles los traería de wikidata. En cuanto a poder construir frases como «la provincia de León cuenta con 468 316 habitantes, siendo sus ciudades más pobladas León (con 125 317 habitantes) y Ponferrada (con 65 788 habitantes)», se puede hacer desde wikidata (es el acceso arbitrario), aunque es más pesado traer datos indicando un Q distinto que el enlazado en el artículo actual. Para el PR:NMSF-AR construí un módulo lua que lo hace ("inspirado" en [5]) y funciona bien (y se cachea por lo que no es tan pesado tampoco).

Yo puedo ayudar con los datos de municipios de Argentina, y al módulo población lo haría lo más genérico posible, si se pude traer la información de las referencias desde wikidata, mejor. Saludos, Juanman (discusión) 16:00 17 feb 2019 (UTC)

Wikidata weekly summary #352

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • Open request for adminship: NewDataB
  • New request for comments: semi-protection to prevent vandalism on most used Items, Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)

• Events
  • February 19th: Wikidata meetup in London - Facebook event
  • February 21st to 24th: International Mother Language Day edit-a-thon
  • February 23rd: editathon about Parliament of Ghana in Accra - Registration
  • March 28th: GLAM & Wikidata day in Switzerland (registration running until March 18th)

• Press, articles, blog posts
  • Let’s Tango: Computational Musicology Using Wikidata, MusicBrainz and the Wolfram Language, by Toni Schindler

• Other Noteworthy Stuff
  • Got some time? Add QIDs to the tools on Edit items, Query data, Enhance user interface, Visualize data, Lexicographical data, For programmers and List of properties. If some tools don't have their own Items, feel free to create them.
  • Hardware issues at Toolforge and CloudVPS affect lots of tools and coincide with changes in the statement stats dynamics
  • WikibaseCirrusSearch will become a Mediawiki extension
  • You can still help Shani Evenstein with her research: Wikidata as a Learning Platform

• Did you know?
  • Newest properties:
    • General datatypes: drag coefficient, illiterate population, literate population, non-free artwork image URL, taxon author citation, total goals in career, stall speed
    • External identifiers: Enciclopedia delle donne ID, Joan Miró Online Image Bank ID, BIDICAM authority ID, Board Game Atlas ID, BVPH authority ID, CCBAE publication ID, ISTC No., KSI player ID, Biblioteca Virtual Andalucía authority ID, Georgian National Filmography ID for Persons, JWF Wrestlers Database person ID, Indian census area code (1991), Lithuanian Sport Encyclopedia (LSE) article ID, Eliseu Visconti Project ID, UN/CEFACT common code
  • New property proposals to review:
    • General datatypes: ScaleNet ID, Lokalhistoriewiki article, Identifiant itch.io, approach angle, departure angle, ride height, type of front suspensions, type of rear suspensions, Football Money League rank, is model of, constraint clarification, has phenotype, observed in, replacement property, evidenční číslo domu, Stack Exchange site
    • External identifiers: WhoSampled artist, äriregister, ISO 639-3 Change Request ID, Queerly Represent Me identifier, V.League player ID, Martindale-Hubbell profile, Google Play Movies & TV id, Fondation Maeght ID, identifiant d'un jeu de données sur data.gouv.fr, BHL part ID, ETS Designated Institution code, Gateway to Research Project ID, Yandex.Music label ID, Yandex.Music genre ID
  • Query examples:
    • Bubble chart of Indian universities with the most people ever employed by them (source)
    • Graph of shared borders between certain West Bengal community development blocks (source)
    • Tree map of ambassadors to India (source)
    • Fictional swords (source)
    • Taxa named after women scientists (source)
    • Timeline of red pandas (source)

• Development
  • Improve the tools dropdown on query.wikidata.org, which now links Tools categories and the Toolforge (phabricator:T214577)
  • Implement the diff view for Schemas (phabricator:T214396, phabricator:T215514)
  • Implement undo for Schemas (phabricator:T214914)
  • Prevent redirecting an entity to itself (phabricator:T214775)
  • Make pressing enter when editing a lemma save the lemma (phabricator:T206140)
  • Strip whitespace around sense glosses (phabricator:T212019)
  • Create LilyPond datatype (phabricator:T215284)
  • More work to get the new version of the termbox readable on mobile

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
  • Suggested and open tasks!
  • 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!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:36 18 feb 2019 (UTC)

Tech News: 2019-08

Las últimas noticias de tecnología de la comunidad técnica de Wikimedia. Coméntale a otros usuarios acerca de estos cambios. Algunos cambios no te afectarán. Existen traducciones disponibles.

Cambios recientes

• Cuando agradezcas a alguien en la versión web para móviles, tendrás dos segundos para cancelar la acción. Esto es en caso que accidentalmente presiones el botón. [6]

Cambios de esta semana

• La nueva versión de MediaWiki estará disponible en las wikis de prueba y Mediawiki.org desde 19 febrero. Se habilitará en las wikis que no sean Wikipedia y en algunas Wikipedias el 20 febrero. Se disponibilizará en todas las wikis desde el 21 febrero (calendario).

Reuniones

• Puedes unirte a la reunión de asesoramiento técnico en el IRC. Durante la reunión, los desarrolladores voluntarios pueden pedir consejo. La reunión será el 20 febrero a las 16:00 (UTC). Mira cómo unirte.

Cambios futuros

• Existe una propuesta para añadir los enlaces en rojo a los resultados de búsqueda móvil si no existe una página con ese nombre. Es así cómo está funcionando en la versión de escritorio. Puedes dejarnos comentarios acerca de esta propuesta. [7]

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.

23:13 18 feb 2019 (UTC)

Tablas y el Editor Visual

Hola a todos. He empezado a utilizar el Editor Visual para algunas ediciones, más que nada influenciado por lo bien que funciona en otra Wikipedia, principalmente por lo fácil que es editar las tablas con el Editor Visual. Esto último me ha resultado engorroso algunas veces, ya que el editor me envía a una plantilla en que debo buscar una a una la edición que deseo modificar. Por ello, muchas veces me paso al editor de código. No sé por qué pasa esto en algunas tablas, ya que en otras es sencillísimo editar. Ahora bien, creo que es momento de evaluar al Editor Visual, puesto que al compararlo al de otra Wikipedia es menor su usabilidad. Alguna encuesta o algo que indique el porqué muchos no usaríamos completamente el Editor Visual que ya lleva más de 3 años, qué falta mejorar y qué incluir. Hay aspectos que me consta que pueden ser incluidos, como los mensajes predefinidos y que aún no están habilitados, para dicho editor, en esta Wikipedia. Saludos. Penquista (Que no te vaya bien... ¡Que te vaya excelente! ©) 00:35 19 feb 2019 (UTC)

Hola Penquista. Acerca de lo que comentas, ¿cuál es la otra Wikipedia?. Te pregunto ya que deberíamos estudiar qué implementación posee y qué elementos faltarían para mejorar la versión de la Wikipedia en español. En este estudio se debe evaluar si es necesario abrir un ticket en Phabricator o poseemos una versión más desactualizada por un plan de lanzamientos parcializados en versiones de distintas Wikipedias, como lo fue en un principio. Saludos Superzerocool (el buzón de msg) 16:19 19 feb 2019 (UTC)

Hola, Superzerocool. Me refiero a Wikipédia (en francés) en donde edito regularmente ¡y por Dios que es fácil usar el Editor Visual allá! Claro, hay algunas cosas que no funcionan muy bien, pero van muy bien encaminados. Saludos. Penquista (Que no te vaya bien... ¡Que te vaya excelente! ©) 16:25 19 feb 2019 (UTC)

@Penquista, ¿y podrías describir algún ejemplo donde la usabilidad en frwiki sea mejor que en eswiki? Porque tras realizar unas pequeñas pruebas no logro ver la diferencia —salvo que nosotros no tenemos cubiertos los parámetros TemplateData en bastantes plantillas—. -- Leoncastro (discusión) 21:59 19 feb 2019 (UTC)

@Leoncastro. Claro que lo dije, en el encabezado de este hilo y en mi primera intervención. Las tablas son muy fáciles de editar, los mensajes predefinidos están en el editor visual (aunque desconozco el porqué me funcionan solo en mi primera edición en un artículo, vuelve a funcionar si cambio a otro artículo) ¡ah! y Provelt allá no deja 2019-02-19 como acá. Saludos. Penquista (Que no te vaya bien... ¡Que te vaya excelente! ©) 22:08 19 feb 2019 (UTC)

Es que en la edición de tablas yo no veo diferencia, por eso pedía un ejemplo concreto. ProveIt es una herramienta independiente del editor visual, por lo que supongo que se tratará de configurarla adecuadamente para obtener las fechas correctas. Precisamente se anunció recientemente que Sophivorus está solicitando un grant rápido para mejorar ProveIt. Será cuestión de pedirle que revise esas fechas. -- Leoncastro (discusión) 22:43 19 feb 2019 (UTC)

Idiomas

Hola a todos. Me he dado cuenta de que no solamente el Editor Visual añade el país en que se se supone que está escrito (Español chileno, español venezolano, «español latinoamericano» ¿cuál es ese?) sino que además asume que un artículo debe estar en inglés, por el sitio web al que está enlazado. Así me encontrado con enlaces a bbc.com que están escritos en español, pero el Editor Visual agrega que está en «Inglés británico», por ser de la BBC. ¿Alguna forma de arreglar eso? Saludos. Penquista (Que no te vaya bien... ¡Que te vaya excelente! ©) 21:00 23 feb 2019 (UTC)

Primero: el «español latinoamericano», alias es-419, es uno de los códigos de idioma definidos según RFC 5646, para identificar el conjunto de idiomas en español de la región de América Latina y el Caribe definida por la ONU. Este sistema de codificación complementa la norma ISO 639-1 según el dialecto o la región geográfica, y se usa habitualmente en entornos automáticos. Por tanto «español latinoamericano» es válido para definir un idioma (o conjunto).

Segundo: la extensión Citoid del Editor Visual usa los servicios de Zotero para extraer los datos necesarios para generar automáticamente las referencias desde las páginas web allí configuradas. Este servicio tiene incorrectamente fijado el idioma para las páginas de la BBC, cuando debería extraer el dato del propio código HTML. Propuse una solución aquí, pero a ver cuando la atienden pues tienen otros 62 cambios anteriores pendientes. -- Leoncastro (discusión) 23:43 23 feb 2019 (UTC)

Plantillas de nombres de buques.

¿Porqué las plantillas ARA o USS ya no ponen los nombres de los buques en cursiva?

Antes se ponía {{ARA|Almirante Brown|D-10}} y salía ARA Almirante Brown (D-10). Hoy se pone lo mismo y sale así, sin la cursiva: ARA Almirante Brown (D-10).

--Gran Chaparral (discusión) 20:16 24 feb 2019 (UTC)

@Gran Chaparral, porque «Los nombres propios, incluidos los de barcos, no van en cursiva nunca». En WP:CURSIVA se dice que «Se usa cursiva para los títulos de las obras de creación literarias y artísticas [...] (se excluyen expresamente [...] las obras de arquitectura e ingeniería: edificios, puentes...)». Ahí hay que agregar los buques como obras de ingeniería, y por tanto excluidas de llevar cursiva. -- Leoncastro (discusión) 20:33 24 feb 2019 (UTC)

Wikidata weekly summary #353

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New request for comments: Talk pages consultation 2019 (feel free to add more sub-sections)

• Events
  • Past: Wikidata hackathon in Ulm with Open Knowledge Foundation. Video of the presentation of the projects (in German)
  • Running until March 2nd: International Mother Language Day edit-a-thon
  • Upcoming: Wikidata and the Diversity of Knowledge workshop in Graz, Austria, on March 3rd
  • Upcoming: Wikidata meetup in Berlin, March 12th
  • Upcoming: Wikidata meetup in Paris, March 15th
  • Upcoming: Wikidata & Wikipedia workshop in Aberdeen, Scotland, on March 19th

• Press, articles, blog posts
  • Inside the Alexa-Friendly World of Wikidata, by Tom Simonite on Wired
  • Align BNF's video games and Wikidata with Dataiku DSS (in French) by Envel Le Hir

• Other Noteworthy Stuff
  • If you're using Wikidata's data dumps, you may want to give feedback on a potential change about when those dumps are generated (ticket)
  • Some games and tools developed during the Wikidata hackathon in Ulm:
    • Card game generator
    • Multiplayer game Guess the (German) Politician
    • Telegram bot @WikidataMisfitBot, sending pictures with one wrong label
    • WikiProjekt offeneregister.de
  • If you're developing new tools or hear about new tools, please add them to Wikidata:Tools so other people can find them :)

• Did you know?
  • Newest properties:
    • General datatypes: expression of, provisional house number in the Czech Republic, has role in modeling, observed in, has phenotype, type of front suspension, type of rear suspension
    • External identifiers: AICTE Permanent ID, DOGC ID, DoBIH Number, ScaleNet ID, WhoSampled artist ID, Business Registry code (Estonia), ISO 639-3 Change Request ID, Lokalhistoriewiki article, Crew united person ID, Fondation Maeght artist ID, data.gouv.fr dataset ID, V.League men's player ID, V.League women's player ID
  • New property proposals to review:
    • General datatypes: Total assists in career, Total points in career, Career plus-minus rating, Penalty minutes in career, Total power play goals in career, Total power play assists in career, Total shots in career, MeSH Descriptor, Former street name
    • External identifiers: NZ On Screen person ID, NZ On Screen work ID, Brazilian Electoral Unit ID, Catálogo de Patrimonio Cultural de Castilla-La Mancha ID, PCAD firm ID, Inventário dos Monumentos RJ ID, SICRIS researcher ID, Physics History Network ID, Sachsen-Anhalt Schutzgebiete-ID, Amis du Louvre ID, Nationation Wrestling Hall of Fame d'un lutteur, Brillant Wiki ID, Official Charts artist ID, Nationation Wrestling Hall of Fame d'une équipe universitaire, Dimensions.guide ID, SensaCine movie ID, SensaCine series ID, Bilibili channel ID
  • Query examples:
    • Women having a good or featured article on Russian Wikipedia but no article on French Wikipedia (source)
    • Timeline of Renaissance humanists (source)
    • Map of cities from the Hanseatic League (source)
    • Image gallery of musicians who have a software title named after them (source)
    • Frequency of first letter in Breton words in Wikidata (source)
    • Items about buildings with coordinates and at least one sitelink, but no image (source)

• Development
  • Updated some icons with the new WikimediaUI icon set (phab:T209259)
  • Fixed an issue that was causing occasional failures when creating new Items (phab:T194299)
  • Investigated Wikidata Tours not loading correctly (phab:T215919)
  • Adjusted spacing between Sense ID, bar and Gloss (phab:T215502)
  • Fixing a long time issue with introducing new data types in production (phab:T216728)
  • Fixing docs for backup of wikibase container images (phab:T214941)
  • Making undo, rollback and restore work on schema content pages (phab:T214399)
  • Improving edit summaries for schema content pages (phab:T213724)
  • Tightening up the process for editing "identifying information" for Schemas (phab:T214466)

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
  • Suggested and open tasks!
  • 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!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:58 25 feb 2019 (UTC)

Tech News: 2019-09

Las últimas noticias de tecnología de la comunidad técnica de Wikimedia. Coméntale a otros usuarios acerca de estos cambios. Algunos cambios no te afectarán. Existen traducciones disponibles.

Cambios recientes

• Existe una nueva versión de la app de Wikipedia para iOS. Tiene, por ejemplo, resaltado de sintaxis y nuevas barras de herramientas que hacen más sencillo editar wikitexto. También incorpora un modo noche, una función para buscar en las páginas y muchas más cosas. Puedes comentar y hacer sugerencias. [8]

Cambios de esta semana

• When you look at your watchlist or the recent changes page you can use the new filters for edit review. There you can choose tags to filter different edits. Empty tags will no longer be shown. [9]
• La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 26 febrero. Se instalará en wikis que no son Wikipedia y en algunas Wikipedias a partir del 27 febrero, y en las restantes a partir del 28 febrero (calendario).

Reuniones

• Puedes unirte a la reunión de asesoramiento técnico en el IRC. Durante la reunión, los desarrolladores voluntarios pueden pedir consejo. La reunión será el 27 febrero a las 16:00 (UTC). Mira cómo unirte.

Cambios futuros

• La aplicación de Wikipedia para Android invitará a los usuarios a añadir las descripciones a los objetos de Wikidata que poseen artículos en Wikipedia pero no tienen descripción en Wikipedia. Se invitará solamente a los usuarios que han añadido descripciones de Wikidata en la aplicación sin que hubieran sido revertidos. Esto último permitirá evitar el spam y las ediciones erróneas. Puedes leer más y dejar comentarios.

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

21:16 25 feb 2019 (UTC)