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

De Wikipedia, la enciclopedia libre

Archivo


17:11 4 feb 2019 (UTC)

Wikidata weekly summary #350[editar]

Ayuda, plantilla[editar]

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[editar]

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

18:45 11 feb 2019 (UTC)

Wikidata weekly summary #351[editar]

Borrar página de desambiguación[editar]

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[editar]

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[editar]

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[editar]

¡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?[editar]

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[editar]

¿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)
-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[editar]

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 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[editar]

23:13 18 feb 2019 (UTC)

Corrector ortográfico[editar]

¿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)
-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[editar]

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 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[editar]

23:13 18 feb 2019 (UTC)

Tablas y el Editor Visual[editar]

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[editar]

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.[editar]

¿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[editar]

21:16 25 feb 2019 (UTC)