Wikcionario:Café

El Café de Wikcionario
Esta página es para todo tipo de conversaciones y preguntas respecto a Wikcionario en español.
Antes de participar, ten en cuenta: Para presentar preguntas sobre alguna entrada en particular, ve a Consultas. Para solicitar la creación de una entrada, visita Solicitudes. Si buscas donde colaborar, aquí tienes un listado de términos que necesitan ser mejorados. Las conversaciones inactivas (más de un mes sin ediciones) están en el Archivo del café. Por favor, después de editar, pon un comentario en el resumen (la síntesis del tema sobre el que aportas o comentas) para que se pueda ver en la página de cambios recientes. ¡Gracias!
Para abrir un nuevo tema de conversación, pulsa aquí
Bots: Las solicitudes para el permiso de bot se harán en esta página. Este wiki usa la política estándar de robots y permite tanto a los robots globales como la aprobación automática de ciertos tipos de robots. El resto de robots debe solicitar ser autorizado en esta página. Un burócrata revisará y decidirá sobre la solicitud. Bots (English): Requests for the bot flag should be made on this page. This wiki uses the standard bot policy, and allows global bots and automatic approval of certain types of bots. Other bots should apply below. A local bureaucrat will review and decide upon your aplication.

Archivo del Café
Antes de junio de 2009
Desde junio de 2009
Año corriente (2024):
<enero> <febrero> <marzo> <abril> <mayo> <junio> <julio> <agosto> <septiembre> <octubre>

Atajo:
WN:C

	Esta página es archivada por Grillitus. (info)
	Parámetros del archivado: lugar: Wikcionario:Café/AAAA MM Días a mantener: 21 Avisar al archivar: Sí Estrategia: Firma más reciente en la sección

Archivo de noviembre 2024

Tech News: 2024-45

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

Updates for editors

• Stewards can now make global account blocks cause global autoblocks. This will assist stewards in preventing abuse from users who have been globally blocked. This includes preventing globally blocked temporary accounts from exiting their session or switching browsers to make subsequent edits for 24 hours. Previously, temporary accounts could exit their current session or switch browsers to continue editing. This is an anti-abuse tool improvement for the Temporary Accounts project. You can read more about the progress on key features for temporary accounts. [1]
• Wikis that have the CampaignEvents extension enabled can now use the Collaboration List feature. This list provides a new, easy way for contributors to learn about WikiProjects on their wikis. Thanks to the Campaign team for this work that is part of the 2024/25 annual plan. If you are interested in bringing the CampaignEvents extension to your wiki, you can follow these steps or you can reach out to User:Udehb-WMF for help.
• The text color for red links will be slightly changed later this week to improve their contrast in light mode. [2]
• View all 32 community-submitted tasks that were resolved last week. For example, on multilingual wikis, users can now hide translations from the WhatLinksHere special page.

Updates for technical contributors

• XML data dumps have been temporarily paused whilst a bug is investigated. [3]

In depth

• Temporary Accounts have been deployed to six wikis; thanks to the Trust and Safety Product team for this work, you can read about the deployment plans. Beginning next week, Temporary Accounts will also be enabled on seven other projects. If you are active on these wikis and need help migrating your tools, please reach out to User:Udehb-WMF for assistance.
• The latest quarterly Language and Internationalization newsletter is available. It includes: New languages supported in translatewiki or in MediaWiki; New keyboard input methods for some languages; details about recent and upcoming meetings, and more.

Meetings and events

• MediaWiki Users and Developers Conference Fall 2024 is happening in Vienna, Austria and online from 4 to 6 November 2024. The conference will feature discussions around the usage of MediaWiki software by and within companies in different industries and will inspire and onboard new users.

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

MediaWiki message delivery 20:50 4 nov 2024 (UTC)

Tech News: 2024-46

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

Updates for editors

• On wikis with the Translate extension enabled, users will notice that the FuzzyBot will now automatically create translated versions of categories used on translated pages. [4]
• View all 29 community-submitted tasks that were resolved last week. For example, the submitted task to use the SecurePoll extension for English Wikipedia's special administrator election was resolved on time. [5]

Updates for technical contributors

• In 1.44.0-wmf-2, the logic of Wikibase function getAllStatements changed to behave like getBestStatements. Invoking the function now returns a copy of values which are immutable. [6]
• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. The API will be rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints. The impacted endpoints include getting page/revision metadata and rendered HTML content. These changes will be available on testwiki later this week, with other projects to follow. This change should not affect existing functionality, but active users of the impacted endpoints should verify behavior on testwiki, and raise any concerns on the related Phabricator ticket.

In depth

• Admins and users of the Wikimedia projects where Automoderator is enabled can now monitor and evaluate important metrics related to Automoderator's actions. This Superset dashboard calculates and aggregates metrics about Automoderator's behaviour on the projects in which it is deployed. Thanks to the Moderator Tools team for this Dashboard; you can visit the documentation page for more information about this work. [7]

Meetings and events

• 21 November 2024 (8:00 UTC & 16:00 UTC) - Community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year. The theme of this call is how content should be organised on Wikimedia Commons.

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

MediaWiki message delivery 00:07 12 nov 2024 (UTC)

Tech News: 2024-47

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

Updates for editors

• Users of Wikimedia sites will now be warned when they create a redirect to a page that doesn't exist. This will reduce the number of broken redirects to red links in our projects. [8]
• View all 42 community-submitted tasks that were resolved last week. For example, Pywikibot, which automates work on MediaWiki sites, was upgraded to 9.5.0 on Toolforge. [9]

Updates for technical contributors

• On wikis that use the FlaggedRevs extension, pages created or moved by users with the appropriate permissions are marked as flagged automatically. This feature has not been working recently, and changes fixing it should be deployed this week. Thanks to Daniel and Wargo for working on this. [10][11]

In depth

• There is a new Diff post about Temporary Accounts, available in more than 15 languages. Read it to learn about what Temporary Accounts are, their impact on different groups of users, and the plan to introduce the change on all wikis.

Meetings and events

• Technical volunteers can now register for the 2025 Wikimedia Hackathon, which will take place in Istanbul, Turkey. Application for travel and accommodation scholarships is open from November 12 to December 10 2024. The registration for the event will close in mid-April 2025. The Wikimedia Hackathon is an annual gathering that unites the global technical community to collaborate on existing projects and explore new ideas.
• Join the Wikimedia Commons community calls this week to help prioritize support for Commons which will be planned for 2025–2026. The theme will be how content should be organised on Wikimedia Commons. This is an opportunity for volunteers who work on different things to come together and talk about what matters for the future of the project. The calls will take place November 21, 2024, 8:00 UTC and 16:00 UTC.
• A Language community meeting will take place November 29, 16:00 UTC to discuss updates and technical problem-solving.

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

MediaWiki message delivery 02:00 19 nov 2024 (UTC)

Propuesta de reducir (aun más) parámetros de pron-graf

Creo haber solicitado permiso para borrar algún que otro parámetro de esta plantilla debido a que al haber implementado los módulos se volverían muy innecesarios. En realidad, ahora vengo a preguntar si estaría bien eliminar varios parámetros que nunca fueron usados a gran escala:

• |s (|salt, |snota, etc.) : esta serie de parámetros era una fila adicional en la versión antigua de la plantilla, supuestamente para “palabras que también se representan con símbolos”, pero nunca se explicó en la documentación y en la práctica fue más común optar por “grafía alternativa”. -> unifico a |g (grafía alternativa).
• |ts y derivados: esta serie de parámetros apuntaba a indicar una “transcripción silábica”, una transliteración de una grafía diferente pero agregando una separación en sílabas. Lo cierto es que como la transliteración debería poder pronunciarse desde el punto de vista del español, la separación en sílabas queda implícitamente aclarada, por lo que resulta redundante.
• |e y derivados: esta serie de parámetros se utilizaba para indicar “escrituras alternativas”. Se diferenciaba de las “grafías alternativas” en cuanto que vincula palabras de sistemas de escritura distintos entre un mismo idioma, como ocurre con el japonés entre el hiragana y el katakana. En la práctica, lo más común fue utilizar “grafía alternativa” y agregar una nota adicional indicando la escritura correspondiente. Por lo que pronongo unificarlo a |g (grafía alternativa).
• Todos los parámetros que terminen en “num”: recientemente en la guía de estilo agregué un criterio para ordenar las etimologías en el que básicamente se usa el criterio histórico. En general referenciar a otra entrada agregando el número de etimología me parece mala idea porque si se debe reordenar el orden en la página de esa palabra hay que cambiar los números en todas las que apunten a esa referencia. En mi opinión, no es necesario aclarar el número porque al cotejar las páginas de la página que referencia y la referenciada uno se da cuenta si por ejemplo una variante aplica a todas las etimologías o a una sola. En los pocos casos en los que haya ambigüedad, preferiría añadir una nota aclaratoria diciendo el sentido al que aplica. Esto aplica en general, tanto para palabras referenciadas con esta plantilla, como para palabras referenciadas en otra parte de la página.
• Todos los parámetros que terminen con “tr”: agrega una transliteración a la variante o grafía alternativa, redundante en mi opinión ya que se puede acceder a la página correspondiente y leer la transliteración en su propia plantilla de pron-graf.

Las páginas con estos parámetros son menos de 300 [12]. Implementando estos cambios, la plantilal de pron-graf quedaría con, además de los parámetros “fonéticos”, parámetros para indicar variantes, grafías alternativas, homófonos y parónimos; cada uno con su “alt” (altera la apariencia) y “nota” (para agregar una nota a pie de página). No creo que se necesite más que eso. Tmagc (discusión) 15:21 20 nov 2024 (UTC)

Sign up for the language community meeting on November 29th, 16:00 UTC

Hello everyone,

The next language community meeting is coming up next week, on November 29th, at 16:00 UTC (Zonestamp! For your timezone <https://zonestamp.toolforge.org/1732896000>). If you're interested in joining, you can sign up on this wiki page: <https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/Community_meetings#29_November_2024>.

This participant-driven meeting will be organized by the Wikimedia Foundation’s Language Product Localization team and the Language Diversity Hub. There will be presentations on topics like developing language keyboards, the creation of the Moore Wikipedia, and the language support track at Wiki Indaba. We will also have members from the Wayuunaiki community joining us to share their experiences with the Incubator and as a new community within our movement. This meeting will have a Spanish interpretation.

Looking forward to seeing you at the language community meeting! Cheers, Srishti 19:55 21 nov 2024 (UTC)

Propuesta para eliminar páginas con enclíticos

Segunda propuesta: hay unas pocas páginas en el sitio de verbos con enclíticos. La idea es borrar casi todas, sino todas. Motivo? Es innecesario agregar más conjugaciones para cada forma canónica, ya hay bastantes sin considerar formas compuestas ni pronominales, etc. No veo cómo puede aportar valor al proyecto por lo que deberían ser borradas a menos que estén lexicalizadas con alguna definición diferente a la forma canónica, en cuyo caso se requeriría agregar la página pero introduciendo esta nueva definición. Tmagc (discusión) 15:29 20 nov 2024 (UTC)

¿Por qué para usted esas formas carecen de valor?  Ivanics (Res publica non dominetur) 00:04 21 nov 2024 (UTC)

quítalo = quita + lo. Lo considero un caso de suma de las partes. Si consideramos que las combinaciones es con lo/los/la/las/le/les es sumar seis formas flexivas más. Si agregamos quita+lo/los/la/las/le/les quitar+lo/los/la/las/le/les, quitándo+lo/los/la/las/le/les ya son 24 formas flexivas extra por cada verbo. Eso sería llenar la base de datos con más entradas que no aportan nada de información nueva, la regla para construir verbos enclíticos es prácticamente universal para todos los verbos. Tmagc (discusión) 00:14 21 nov 2024 (UTC)

Según ese argumento, también deberían borrarse las formas correspondientes a la conjugación de los verbos regulares, porque siguen una norma «prácticamente universal» para construirlos.  Ivanics (Res publica non dominetur) 00:20 21 nov 2024 (UTC)

Exacto! Solo que 1. hay varios verbos irregulares lo que de algún modo justificaría tener páginas aparte y 2. si fuera por mí borraría todas las entradas de formas flexivas porque no aportan nada de información nueva, solo dejaría la tabla de conjugación en la forma canónica y las formas no canónicas solo las que están lexicalizadas como pagaré, pero sería un cambio muy grande como para hacerlo en el corto plazo aunque no lo descarto. En cambio los enclítios son siempre regulares y por ahora solo hay 59 Categoría:ES:Formas con enclíticos. Estamos a tiempo de evitar que se propague el vicio. Tmagc (discusión) 00:49 21 nov 2024 (UTC)

Muy en contra. El valor de Wikcionario por sobre un diccionario impreso común y corriente está en tener el potencial de ser un catálogo de todas las palabras existentes, incluyendo flexiones, conjugaciones, variantes, diminutivos, etcétera; lo que puede brindar un valor de uso importante para las personas que están aprendiendo un idioma, inteligencias artificiales, lingüistas e incluso hablantes comunes de un idioma.  Ivanics (Res publica non dominetur) 01:04 21 nov 2024 (UTC)

A favor. Como decía en Discusión:quítalo, prefiero borrarlas ahora para hacer las cosas bien después, si es que así lo decidimos. @Tmagc: son muchas más de 24 por verbo si consideramos también las formas literarias/poéticas/potenciales como quitelo (= lo quité), quitaríamoslas (= las quitaríamos), etc. Si abrimos un melón, que sea con perspectiva: hemos necesitado 20 años para crear 59 entradas de una categoría que debería alojar millones, por lo que no aprecio su valor actual. @Ivanics: si un lingüista acude a nosotros, esto nos dejará en evidencia. Peter Bowman (discusión) 20:21 21 nov 2024 (UTC)

Mientras aceptemos tener formas no canónicas no veo motivo para sacar este pequeño subconjunto y conservar todo el resto. A menos que cause problemas diferentes al resto. ¿Es así? Saludos. Lin linao ¿dime? 15:22 22 nov 2024 (UTC)

Si el día de mañana acordamos poner en marcha un bot para que cree estas entradas en masa acorde a una plantilla, será más fácil partir desde cero que "rellenar huecos", por así decir, evitando pisar esas 59 formas que ya existen. Si en vez de 59 son 590, seguirán teniendo un valor insignificante, pero para nosotros supondrán más trabajo de cara a la revisión y posterior adaptación al formato que establezcamos. Yo en esa situación preferiría simplemente sobreescribirlas, entonces ¿para qué dejar que proliferen? La única forma de hacerlo bien es con un bot, y poner coto a su creación cuanto antes. Si el día de mañana llega alguien a Wikcionario y se propone crearlas manualmente, no querría tener que decirle que su trabajo es en vano, por el escaso o nulo impacto que va a tener, para que luego además venga un bot y se lo pise todo. Peter Bowman (discusión) 19:23 22 nov 2024 (UTC)

A mí esta propuesta me recuerda lo que pasó con el caso de los anagramas y pares mínimos: Tmagc procedió a su retiro con el argumento de que es un proceso automatizable y por tanto no tiene justificación invertir tiempo de trabajo humano en su realización. Sin embargo, nunca se ha puesto sobre la mesa un cronograma de automatización de ese proceso, sino que se ha pasado a otras tareas. En consecuencia, Wikcionario hoy tiene menos información de la que tenía hace un año, pero con la diferencia que ahora su incorporación queda completamente por fuera del campo de acción de los usuarios comunes y corrientes.  Ivanics (Res publica non dominetur) 23:52 22 nov 2024 (UTC)

Hablar de cronogramas no tendría sentido en un proyecto que es a voluntad, las cosas se hacen en la medida que se cuenta con el tiempo. En cuanto a los anagramas, ya está incorporado Wikcionario:Anagramas. En cuanto a los pares mínimos, todavía faltaría terminar de homogenizar pron-graf para parsear la base de datos pero lo tengo en mi lista de pendientes. En cuanto a los supuestos usuarios “comunes y corrientes”, justamente todas estas propuestas apuntan a incentivar a que agreguen léxico y a desincentivar tareas que son relativamente fáciles de automatizar. Bien que desde que inició el proyecto mucho chicherío pero ni siquiera está completo con las palabras de la base de datos del DLE, lo mínimo por donde se debería comenzar en cualquier diccionario. Pero de todas formas no hay nada que quede fuera del alcance de nadie, el código de las tareas de mi bot creo que se puede ver en Toolforge y si es mucho problema puedo publicar el repositorio para que se entretenga un rato si lo desea. No sé a lo que apuntaba el comentario pero menos información? Recuerdo que teníamos 920k entradas hace un año y ahora estamos cerca de 935k. Tmagc (discusión) 00:58 23 nov 2024 (UTC)

@Ivanics: sugiero que nos centremos en el tema que nos ocupa, porque en tu voto y comentarios parece que estás en otra discusión. Claramente, sí, la cuestión de los enclíticos queda fuera del campo de acción de los usuarios comunes y corrientes, y el proyecto no notará una pérdida de información por borrar esas 59 entradas. Peter Bowman (discusión) 11:27 23 nov 2024 (UTC)

Precisamente lo que quiero explicar es que el punto es que me parece que se está actuando bajo criterios subjetivos, al punto que no se ha dejado claro cuál es el argumento de borrado ¿Se eliminarían por ser irrelevantes o se eliminan por ser automatizables? Voté en contra porque el argumento que se presentó inicialmente es el primero.

Ahora, si es el segundo, pido amablemente el favor de que se adopte el criterio de no borrar información hasta que se haya implementado el sistema automático, en lugar de seguirlo haciendo al revés. Porque el mencionado carácter voluntario del proyecto hace que no hayan certezas de que haya alguien pendiente de que lo borrado sea restaurado luego, ya que por más que el código sea abierto, la programación es una habilidad menos extendida que la de editar código Mediawiki.  Ivanics (Res publica non dominetur) 12:39 23 nov 2024 (UTC)

En mí opinión los enclíticos son irrelevantes, además de ser automatizables. Si no lo son, habría que determinar el criterio para considerar a una página como la mera suma de las partes porque incluso aunque se escriban todo junto los enclíticos no veo cómo le agrega valor al proyecto tenerlos. Parece más una regla universal antes de ser algo que deba documentado acá.

Cierto, esto no es papel pero más allá de eso no le veo mucha diferencia con un diccionario cualquiera: una herramienta de consulta, no de aprendizaje. Se dan definiciones, no explicaciones. Mezclar las dos cosas podría confundir aún más a los lectores. Qué pasa con los millones de enclíticos que no están? Solo valen esos 59 que están ahora? El resto de construcciones enclíticas no son válidas?

Repito: si hay gente que usa un diccionario para aprender, recomiendo que se consigan un curso o lean los articulos de Wikipedia sobre el español. Acá como en cualquier diccionario el que lo usa lo hace para consultar, por lo tanto se asume que ya tiene un dominio claro del idioma. No es necesario confundir a la gente con sobreinformación. Y como ya dije alguna vez antes: si la gente prefiere Wikcionario, va a ser porque encuentren definiciones y léxico que no aparezcan en otros diccionarios, no por cuántos enclíticos aparezcan, ni siquiera porque tengamos páginas con enclíticos. Tmagc (discusión) 18:29 23 nov 2024 (UTC)

El último párrafo es una consideración subjetiva y yo difiero en el por qué la gente puede considerar útil a Wikcionario frente a otros diccionarios, como el de la RAE. Pero todo van a ser sólo opiniones hasta que alguien se anime a hacer un estudio sobre el tema.

Pero repito de nuevo: se están revolviendo dos argumentos antitéticos, el de la automatización y el de la irrelevancia. Hay que decidir cuál de los dos es el correcto, porque si son irrelevantes no tiene sentido automatizar la tarea.  Ivanics (Res publica non dominetur) 17:02 24 nov 2024 (UTC)

• Páginas más visitadas ayer [13]
• Páginas más visitadas el mes pasado [14]
• Páginas más visitadas el año pasado [15]
• Páginas mías más visitadas [16]: son gede y pechofrío. Que yo sepa ninguna está en ningún diccionario.
• Páginas de Ivanics más visitadas [17]

Esporádicamente se cuelan algunas formas flexivas en femenino o en plural. Pero no vi ningún enclítico. Tmagc (discusión) 20:43 24 nov 2024 (UTC)

¿Que las formas no canónicas no sean las más visitadas significa que son irrelevantes?  Ivanics (Res publica non dominetur) 01:54 26 nov 2024 (UTC)

En contra. Hola a todos. Que se programe la automatización primero, o incluso redirecciones automatizadas; luego se eliminen. Pero tener cuidado de no eliminar la página entera cuando tenga acepciones no-flexivas, o secciones en otros idiomas. A quien sea que programe la automatización le doy mis gracias de antemano.— Genoskill (discusión) 23:48 26 nov 2024 (UTC)

Tech News: 2024-48

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

Updates for editors

• A new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature later this week. This brings many new features and bug fixes, including right-to-left support, template folding, autocompletion, and an improved search panel. You can learn more on the help page.
• The 2010 wikitext editor now supports common keyboard shortcuts such Ctrl+B for bold and Ctrl+I for italics. A full list of all six shortcuts is available. Thanks to SD0001 for this improvement. [18]
• Starting November 28, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: bswiki, elwiki, euwiki, fawiki, fiwiki, frwikiquote, frwikisource, frwikiversity, frwikivoyage, idwiki, lvwiki, plwiki, ptwiki, urwiki, viwikisource, zhwikisource. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF).
• View all 25 community-submitted tasks that were resolved last week. For example, a user creating a new AbuseFilter can now only set the filter to "protected" if it includes a protected variable.

Updates for technical contributors

• The CodeEditor, which can be used in JavaScript, CSS, JSON, and Lua pages, now offers live autocompletion. Thanks to SD0001 for this improvement. The feature can be temporarily disabled on a page by pressing Ctrl+, and un-selecting "Live Autocompletion".
• Tool-maintainers who use the Graphite system for tracking metrics, need to migrate to the newer Prometheus system. They can check this dashboard and the list in the Description of the task T350592 to see if their tools are listed, and they should claim metrics and dashboards connected to their tools. They can then disable or migrate all existing metrics by following the instructions in the task. The Graphite service will become read-only in April. [19]
• The New PreProcessor parser performance report has been fixed to give an accurate count for the number of Wikibase entities accessed. It had previously been resetting after 400 entities. [20]

Meetings and events

• A Language community meeting will take place November 29 at 16:00 UTC. There will be presentations on topics like developing language keyboards, the creation of the Mooré Wikipedia, the language support track at Wiki Indaba, and a report from the Wayuunaiki community on their experiences with the Incubator and as a new community over the last 3 years. This meeting will be in English and will also have Spanish interpretation.

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

MediaWiki message delivery 22:42 25 nov 2024 (UTC)

Actual

Support request with team editing experiment project

Dear tech ambassadors, instead of spamming the Village Pump of each Wikipedia about my tiny project proposal for researching team editing (see here: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Research_team_editing), I have decided to leave to your own discretion if the matter is relevant enough to inform a wider audience already. I would appreciate if you could appraise if the Wikipedia community you are more familiar with could have interest in testing group editing "on their own grounds" and with their own guidance. In a nutshell: it consists in editing pages as a group instead of as an individual. This social experiment might involve redefining some aspects of the workflow we are all used to, with the hope of creating a more friendly and collaborative environment since editing under a group umbrella creates less social exposure than traditional "individual editing". I send you this message also as a proof that the Inspire Campaign is already gearing up. As said I would appreciate of *you* just a comment on the talk page/endorsement of my project noting your general perception about the idea. Nothing else. Your contribution helps to shape the future! (which I hope it will be very bright, with colors, and Wikipedia everywhere) Regards from User:Micru on meta.

Sección de referencias en nueva estructura

Hola. Probé la nueva estructura en yam y creo que la sección de Referencias debería ser de tercer nivel (es de segundo), para que cada una quede anidada en el idioma (de segundo) o que la de idioma sea de primer nivel. En ambos casos las jerarquías se desordenan, pero la situación actual tampoco parece buena. Saludos. Lin linao ¿dime? 02:08 30 jun 2015 (UTC)

PS: Otra cosa es que habrá ciertas secciones que sean translingüísticas, como las distintas clases de símbolos (elementos químicos, unidades de medida), y las transliteraciones. Sobre lo segundo, en yam hay una transliteración del hebreo, que en mi opinión no debería figurar como hebreo a secas, pero por ahora no hay modo de anotarla. Saludos. Lin linao ¿dime? 02:31 30 jun 2015 (UTC)

Volveré a las transliteraciones en breve, es uno de los asuntos que me impiden progresar con la conversión.

En cuanto a las referencias, WN:ES contempla incluir una sección común a todas las lenguas, de modo que tu edición era incorrecta (el bot está programado para borrar las secciones de referencias repetidas e incluir una por defecto al pie de página, pero anoche no llegó a procesar esa página a causa de un error en el código, ya subsanado). La alternativa que propones debería ser discutida y aceptada para sustituir a la norma actual (personalmente descartaría los títulos de segundo nivel y con los tags <small>, es algo que estamos procurando evitar en la nueva estructura).

Este es también uno de los temas que quería discutir antes de la edición en masa. He encontrado unas 740 mil páginas que incluyen el título Referencias y notas, de modo que, siguiendo el esquema actual, el bot añadiría dicho título en las cerca de 100 mil entradas restantes. Partiendo de este punto, quería preguntar si hay interés por borrar las secciones de Referencias y notas si no se ha aportado ninguna referencia en la entrada (bien mediante tags <ref>, alguna plantilla o manualmente) y dicha sección se presenta vacía Las alternativas son:

• (opción por defecto, pues es la norma actual) no borrar estas secciones aunque estén vacías, añadirlas en las 100 mil páginas restantes. Es posible escribir un gadget después de la transición que las oculte (nuevamente, solo si están vacías), si bien seguirían presentes en el wikicódigo de la página.
• programar el bot para borrar las secciones vacías, detectando a tal efecto la presencia de tags <ref> u cualquier plantilla que los transcluya, valiéndose para ello de una lista predefinida (nota para mi yo futuro: utilizar una categoría de seguimiento una vez solventado phab:T69700)

Un saludo, Peter Bowman (discusión) 13:09 30 jun 2015 (UTC)

Gracias. No sabía que la idea era tener una sola sección de referencias. Pensaré sobre los dos temas: tener una sección o varias y qué hacer con las entradas en donde no hay referencias. Saludos. Lin linao ¿dime? 01:48 1 jul 2015 (UTC)

Personalmente no estoy de acuerdo con borrarlas o ocultarlas aunque estén vacías, es necesario fomentar la inclusión de referencias, no creamos contenido primario y en realidad no deberían existir entradas sin referencias, yo votaría de hasta le agregarles una nota cuando no haya referencias diciendo "Esta entrada no posee referencias, por favor si puedes incluye alguna"--Esceptic0 (discusión) 15:03 23 jul 2015 (UTC)

La inmensa mayoría de las entradas de Wikcionario son formas flexivas, luego nos podríamos preguntar para qué sirve una sección de referencias en una entrada como zapateéis. Por lo demás, su presencia no guarda tan estrecha relación con la inclusión de referencias como puede parecer en un principio. Recordemos que lo óptimo es añadir fuentes en el cuerpo de la entrada mediante tags <ref>, las cuales aparecerán en una nota al pie independientemente de que esta sección esté presente o no (el bot puede encargarse de añadirla si es conveniente, véase el segundo punto de mi anterior comentario). Por lo general, no hace falta que esta sección sea editada directamente. Un saludo, Peter Bowman (discusión) 17:18 23 jul 2015 (UTC)

totalmente de acuerdo, ahí agregué tu explicación a la plantilla para las futuras dudas que tengan los editores sobre para qué está. Yo había entendido mal y estaba eliminando el <br clear="all"/>--Esceptic0 (discusión) 11:25 7 ago 2015 (UTC)

Nueva estructura: <br clear="all">

Quisiera tratar en este hilo la presencia de estos elementos HTML en las entradas y su lugar tras la conversión a la nueva estructura. Para quienes desconozcan su función, aclaro que consiste en evitar que cualquier elemento flotante invada los elementos situados a continuación de dichos tags <br>, ya sea por la izquierda o por la derecha (esto último es lo más habitual). Los ejemplos más típicos de elementos flotantes son las imágenes o las tablas de flexión que vemos en el margen derecho de las entradas, así como la recientemente creada plantilla {{pron-graf}}. En las siguientes imágenes, tomadas sobre una versión editada de ransack con la tabla de flexión expandida, se puede apreciar la diferencia: imagen a, imagen b. Actualmente, no es necesario incluir ningún artificio adicional (como estos tags) para evitar el solapamiento de elementos respecto de los títulos de nivel 2 en la nueva estructura (secciones de idioma y referencias), pues se encargan de ello estas nuevas reglas que añadí recientemente a Common.css. Imagínese el efecto negativo que supondría que las imágenes, tablas de flexión, etc. de una sección de idioma invadiera el espacio de la siguiente, desplazando a su vez los elementos flotantes de esta y así sucesivamente.

Repasados los encabezamientos del nivel superior, queda analizar las subsecciones dentro de las propias secciones de idioma. Es muy frecuente que haya un <br clear="all"> justo delante del título de una sección que normalmente contiene una tabla u otro elemento que ocupa todo el ancho de la entrada. Es el ejemplo de las tablas de traducciones, locuciones o derivados de otras lenguas (aquí se aprecia que la última imagen desplaza una de estas tablas desplegables, generando un hueco vacío bajo el título Traducciones). Ninud me propuso insertar estos elementos antes de los títulos de etimología (en caso de haber más de uno). Veo dos alternativas:

• Crear una plantilla, llámese por ejemplo {{clear}}, que sustituya a los <br clear="all"> (internamente podría contener un tag <span> o <div> para evitar ese salto de línea adicional que genera un <br>, aunque eso es lo de menos). El bot la añadiría automáticamente donde sea necesaria, y muy posiblemente borraría también otros usos que los editores le decidan dar y no se hayan consensuado antes (es un elemento que afecta a la presentación visual de la entrada, luego no se debería abusar de él). Obviando esto último, esta opción tan solo simplificaría el modo de empleo actual y favorecería la estandarización en caso de adoptar nuevas soluciones (no es raro encontrarse con plantillas de este tipo en otros proyectos).
• Crear un accesorio escrito en JavaScript capaz de detectar las secciones afectadas y aplicarles la regla CSS correspondiente, no permitir el uso de ningún <br clear="all">. No funcionaría en clientes muy antiguos o en el caso de aquellos usuarios que decidan desactivar JS en su navegador, pero aún así no debería afectar más que aun número reducido de lectores (de todos modos, no sería la única funcionalidad de la que se verían privados).

JavaScript aquí no me parece una solución óptima, pero tampoco me convence la presencia en el wikicódigo de elementos aparentemente superfluos y potencialmente desconocidos para el editor novato, que en muchas ocasiones no llegan a cumplir su función a menos que sea añadida una imagen o tabla flotante. En este último caso, es posible que su número se vea reducido en el futuro (Wikcionario:Café/2015 04#declinación de adjetivos latinos). Aprovecho también para comunicar que mi intención es comenzar con el boteo dentro de unas dos semanas. Un saludo, Peter Bowman (discusión) 23:23 19 jul 2015 (UTC)

Nunca había entendido para que aparecía eso, lo dejaba por las dudas, hasta ahora. No está bueno que aparezca en el wikicódigo, si es con una plantilla por lo menos se puede explicar en la documentación de la misma para que se usa pero si se va a poner en todas las entradas sería conveniente que se ponga automáticamente y de forma oculta. No puedo decir más porque no tengo idea.--Esceptic0 (discusión) 14:51 23 jul 2015 (UTC)

Ante la duda, he preferido adoptar la primera solución, más cercana a la práctica actual. Podremos volver a esto en el futuro para recoger más opiniones y analizarlo otra vez. El bot ya ha empezado a colocar la recientemente creada plantilla {{clear}}. Concretamente, la inserta justo antes de aquellas secciones cuyo contenido empieza por una de las siguientes plantillas: {{arriba}}, {{rel-arriba}}, {{trad-arriba}} (ejemplo). La novedad está en que también colocará dicha plantilla antes de las secciones de tipo Etimología X, donde X > 1 (ejemplo; se puede ver que en la sección del Francés antiguo impide que {{pron-garf}} invada la siguiente sección etimológica, donde, por cierto, debería estar otra plantilla de pronunciación). Si alguien observa otro caso donde deba usarse {{clear}}, actualizaré el código para tenerlo en cuenta. Un saludo, Peter Bowman (discusión) 16:36 6 ago 2015 (UTC)

Tech News: 2015-33

Las noticias técnicas más recientes de la comunidad técnica de Wikimedia. Informa sobre estos cambios a otros usuarios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios recientes

• MediaWiki ahora puede ocultar el botón para firmar cuando un editor está trabajando en un espacio de nombres de contenido. [21]
• El mensaje «Se han guardado tus preferencias» cambió. Ahora es más fácil ver lo que fue guardado cuando cambias las preferencias varias veces. [22]
• Ahora es posible reproducir archivos de video Ogg en algunos navegadores que no soportan ese formato. La solución usa JavaScript y solo funciona en los navegadores de escritorio. Pronto estará disponible para los dispositivos móviles. [23]
• Ahora el editor visual permite usar en los navegadores móviles las mismas herramientas para editar estilos que están disponibles en los navegadores de escritorio. [24]
• Ahora es más fácil ver si hay un error de JavaScript en una función de usuario o del sitio. [25]
• Programadores de JavaScript:
  • Ya no pueden usar la biblioteca Sajax. Esta es una lista de las páginas que es necesario arreglar. [26] [27]
  • Ya no pueden usar document.write en las wikis de Wikimedia. Esta es una lista de las páginas que es necesario arreglar. [28] [29]
• La herramienta para traducción de contenidos ahora funciona mejor. Es más fácil usar fórmulas matemáticas y ya no agrega etiquetas innecesarias. [30]

Problemas

• Se arregló un problema que recientemente incrementó la cantidad de ediciones rechazadas debido a la pérdida de datos de sesión. [31]
• Se arregló el problema que en ocasiones afectaba la importación de módulos Lua. [32]
• Se arreglo parcialmente un problema con la herramienta de traducción de contenidos que ocasionaba la pérdida de texto en algunas ocasiones. [33]

Cambios esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 11 de agosto. Se instalará en todas las wikis excepto en las wikipedias el 12 de agosto y en las wikipedias el 13 de agosto (calendario).
• La apariencia del asistente para subir archivos está cambiando. Los botones y casillas de verificación ya fueron modificados. Esta semana se actualizará el selector de fechas. Los otros campos cambiarán pronto. [34]
• Ahora puedes probar el editor visual en dispositivos móviles de todos los tamaños. [35]

Reuniones

• Puedes participar en la siguiente reunión con el equipo del editor visual el 11 de agosto a las 19:00 (UTC). Durante la reunión podrás decirle a los programadores cuales son los defectos más importantes. Consulta cómo participar.

Cambios futuros

• Algunos elementos de la lista de seguimiento tendrán una nueva apariencia. [36]

Noticias técnicas preparadas por embajadores técnicos y publicadas usando un bot • Contribuye • Traduce • Obtén ayuda • Comenta • Suscríbete o cancela tu suscripción.

14:57 10 ago 2015 (UTC)

wikidata

Porqué razón wikidata todavía no tiene incorporado ningún wiktionary? lo harán en el futuro?. Siendo, creo yo, este el proyecto que mas se beneficiaría de esto--Esceptic0 (discusión) 10:32 13 ago 2015 (UTC)

Básicamente, debido a la complejidad del asunto y a la falta de disponibilidad de los desarrolladores :). Se ha realizado una serie de propuestas que puedes consultar aquí. Por lo que puedo ver, ya han empezado a buscar voluntarios para que inicien la primera fase de la última propuesta (centralización de los enlaces interwiki en los artículos del espacio de nombres principal; ver d:Wikidata talk:Wiktionary#First Step, d:Wikidata talk:Wiktionary/Development/Proposals/2015-05#Start?, phab:T987). Un saludo, Peter Bowman (discusión) 11:01 13 ago 2015 (UTC)

=( otra cosa que tampoco tenemos y sería beneficiosa para aumentar la cantidad de artículos nuevos por día es el editor visual, en el francés está implementado--Esceptic0 (discusión) 03:24 14 ago 2015 (UTC)

Me abstuve de votar al respecto en Wikcionario:Café/2015 01#Editor visual porque creo que no se han sopesado todos los pros y contras. Supongo que un editor experimentado apreciará la facilidad de edición de las plantillas, pero me parece que los novatos se perderán completamente (precisamente debido a ese mismo mar de plantillas). Vendría bien crear una especie de guía interactiva integrada en el Editor Visual que indicara qué elementos y en qué lugar se pueden añadir (p. ej. una nueva sección de idioma, una acepción, otra etimología) e impidiera alterar accidentalmente la estructura de las entradas.

Esceptic0: en el hilo archivado mencionaste la posibilidad de introducir citas con plantilla. En pl.wikipedia se usa un accesorio que podría traer aquí, funciona mediante un formulario (en esto se asemeja un poco a lo que tiene el Editor Visual) que se abre al pulsar un botón en la barra de herramientas de edición y solo hay que rellenar los campos, situar el cursor de texto en el lugar deseado y pulsar otro botón para insertar la plantilla: [37]. ¿Es una buena idea? Un saludo, Peter Bowman (discusión) 15:37 14 ago 2015 (UTC)

Todo lo que ayude es buena idea, pienso yo que un editor nuevo no sabe que borrar y que si no debe elegir que borrar y solo rellenar es mucho mas amigable--Esceptic0 (discusión) 20:13 14 ago 2015 (UTC)

plantilla:etimología

Requiere extensión. Actualmente sólo permite tres palabras como antecedentes, pero debe ser cinco. Así que,

Del latín ad, de, in, illam y horam

En lugar de

Del latín ad, de e in

¿Me comprendes? --Romanófilo (discusión, contribuciones) 03:32 15 ago 2015 (UTC)

Romanophile: ¿podrías mostrar un ejemplo de uso en el que observas esa carencia? Me refiero a algo como {{etimología|prefijo|ad|de|in|...}}. La plantilla admite varios modos de funcionamiento y no consigo encontrar en el código el lugar exacto donde quieres añadir otros dos parámetros. Peter Bowman (discusión) 14:32 15 ago 2015 (UTC)

Peter Bowman: adineauri --Romanófilo (discusión, contribuciones) 10:51 17 ago 2015 (UTC)

Hecho, gracias: Especial:Diff/2878844. Un saludo, Peter Bowman (discusión) 11:24 17 ago 2015 (UTC)

Noticias destacadas de Wikimedia, julio 2015

Estas son las noticias destacadas del blog de Wikimedia en julio 2015

• Inicia la Wikipedia en konkaní
• «Participa construyendo los cambios que tu deseas ver»: Leigh Thelmadatter
• Wikidata, pronto en un menú cercano
• Wikimedistas le piden a la Unión Europea que proteja la libertad de panorama
• La Unión Estadounidense por las Libertades Civiles presenta una queja enmendada a nombre de la Fundación Wikimedia
• Obtén las últimas noticias de Wikipedia con IFTTT

About · Subscribe · Distributed via MassMessage (wrong page? Correct it here), 15:05 17 ago 2015 (UTC)

Tech News: 2015-34

Las noticias técnicas más recientes de la comunidad técnica de Wikimedia. Informa sobre estos cambios a otros usuarios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios recientes

• Muchas Wikipedias ahora pueden usar información de cualquier elemento de Wikidata en cualquier artículo. Anteriormente solo podían usar el elemento de Wikidata asociado con el tema del artículo. [38] [39] [40]
• Se arreglaron algunos problemas de autoguardado y otros defectos de la herramienta para traducción de contenidos. Si todavía tienes problemas, puedes reportarlos en la página de comentarios de la herramienta. [41]

Problemas

• Los accesorios viejos que no usan ResourceLoader ya no funcionarán. Será necesario actualizarlos. [42] [43]
• Los servidores de traducción automática y la herramienta de traducción de contenidos tuvieron problemas el 12 de agosto y se resolvieron el mismo día. [44]

Cambios esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 18 de agosto. Se instalará en todas las wikis excepto en las wikipedias el 19 de agosto y en las wikipedias el 20 de agosto (calendario).
• Pronto podrás vigilar cuando algo se agrega o elimina de una categoría. [45]

Reuniones

• Puedes participar en la siguiente reunión con el equipo del editor visual el 18 de agosto a las 19:00 (UTC). Durante la reunión podrás decirle a los programadores cuales son los defectos más importantes. Consulta cómo participar.

Noticias técnicas preparadas por embajadores técnicos y publicadas usando un bot • Contribuye • Traduce • Obtén ayuda • Comenta • Suscríbete o cancela tu suscripción.

16:17 17 ago 2015 (UTC)

Actualización sobre la herramienta de fusión global de cuentas

Estimados usuarios,

Como sabréis desde el equipo técnico de la Fundación se estaba trabajando en una herramienta que permitiese fusionar cuentas globales pertenecientes a un mismo usuario, en el marco del proceso de "finalización SUL". A pesar de los avances que en esa materia se han realizado, desde dicho departamento nos informan que, habiéndose elaborado un prototipo de herramienta, puesta en práctica, ésta ha resultado ser defectuosa, causando serios problemas y no funcionando correctamente con todos los componentes y extensiones de MediaWiki, ni con todas las bases de datos de Wikimedia.

Ello obliga a suspender, una vez más, la implantación de esta herramienta de fusión de cuentas sine die. No obstante os informamos de que ya se está trabajando en una nueva versión de la herramienta y que se espera que pueda estar disponible en el año 2016, aunque dicha estimación puede modificarse al alza o a la baja dependiendo del progreso y las complicaciones que vayan surgiendo entorno al desarrollo de la herramienta así como de la cantidad de personal que esté trabajando en ello. De todas formas, el proceso se prevé lento por la clasificación de herramienta accesoria que tiene este proyecto.

Además, y con el fin de paliar los problemas que se han detectado en esta fase de pruebas, el alcance de la herramienta será mucho más limitado frente al inicialmente previsto. En principio se estima que sólo aquellas cuentas que hayan sido afectadas por el proceso de finalización SUL podrán ser fusionadas, entre otras cosas de las que se nos irán informando.

Lamentamos que la puesta en marcha de esta funcionalidad se vea nuevamente frustrada por las complicaciones técnicas. Desde Meta-Wiki los stewards esperábamos poder empezar a atender solicitudes en breve.

Por ello os pedimos que no acudáis a Meta-Wiki a pedir nuevas fusiones de cuentas, pues éstas serán automáticamente denegadas al no poder ni siquiera estimar que se van a poder procesar en breve. Del mismo modo, aquellas peticiones ya realizadas se verán denegadas.

Un cordial saludo,
-- MarcoAurelio 09:26 18 ago 2015 (UTC)

Entregado por MediaWiki message delivery, el sistema de notificaciones en masa de MediaWiki.

ucf/plm, códigos de idioma

Lo que quiero consultar en esta ocasión son realmente minucias, pero me da grima pensar en editar 835k+ entradas para revertir una de ellas...

• ¿Hay algún inconveniente en cambiar todas las llamadas de la plantilla {{ucf}} a {{plm}}? Aunque la primera parezca tener 668k transclusiones según Especial:PlantillasMásUsadas, esto se debe a que ella misma está transcluida en otras plantillas como {{forma verbo}}. En realidad solo hay 38k llamadas directas a {{ucf}} desde el wikicódigo de las entradas, unas 6 veces más que las que tiene {{plm}}. En Plantilla discusión:ucf se propuso redirigir la forma anglosajona (upper case first) a la española (primera letra mayúscula), de más reciente creación.

Tiene sentido que se prime la versión en castellano. Mientras no se asigne ningún código ISO a alguna de las abreviaturas, no veo mayor problema. --80.31.75.180 11:37 21 ago 2015 (UTC)

Buena observación. Parece que se llegó a usar el código plm para designar un dialecto del musi llamado palembang, al menos hasta que en el 2007 se decidió confluir este y los demás dialectos bajo el código mui ([46], [47]; el portal MultiTree registra una entrada para el palembang de musi bajo la designación no oficial mui-plm: [48]). Hoy dicho código no parece estar ocupado por ningún idioma ([49], [50]). Peter Bowman (discusión) 23:58 21 ago 2015 (UTC)

• La plantilla {{lengua}} no distingue entre mayúsculas e minúsculas en el código de idioma (podemos escribir {{lengua|ES}}, {{lengua|es}} o incluso {{lengua|Es}}). Empecé adoptando la mayúscula por similitud con el nombre de las antiguas plantillas {{ES}} y {{XX-ES}}, y en un principio ese esquema sería adoptado en prácticamente todas las entradas tras la conversión. Por ese motivo, y pretendiendo mantener una coherencia interna, añadí una tarea que convierte el código a mayúsculas donde no aparezca así (ver Especial:Diff/2884175). Sin embargo, es una práctica habitual introducir dicho código en minúsculas en el parámetro leng de muchas plantillas, así como en el primer parámetro sin nombre de las plantillas de sección ({{sustantivo masculino|es}}). ¿Hay alguna preferencia por usar siempre las minúsculas a partir de ahora?

Un saludo, Peter Bowman (discusión) 11:06 21 ago 2015 (UTC)

Yo prefiero los códigos de idioma en minúsculas, que es como aparecen los códigos ISO 639-* y los códigos ad-hoc de Wikimedia, y ya que ahora en los encabezados aparecen como parámetro, deberían igualarse en mi opinión. Los encabezados en mayúsculas son parte de la herencia arrastrada, pero ya que se entra en faena veo más coherente la preferencia de las minúsculas que de las mayúsculas. Saludos --80.31.75.180 11:37 21 ago 2015 (UTC)

No tengo preferencia sobre las mayúsculas o minúsculas, sobre ucf a plm mientras no rompa nada por su puesto A favor, hay que trasladar el código de ucf en plm y redirigir ucf a plm--Esceptic0 (discusión) 12:06 21 ago 2015 (UTC)

Prefiero las minúsculas en los códigos y plm si no se rompe nada. Sobre los códigos de idioma, haría falta una revisión de coherencia: iso 639-2 > iso 639-3 > ¿SIL (creo que siempre coincide con ISO, pero no estoy seguro), Linguistlist > Glottolog? Lin linao ¿dime? 16:15 21 ago 2015 (UTC)

Gracias por la pronta respuesta :). Seguiré con la conversión {{ucf}} → {{plm}}, y empezaré a usar las minúsculas por defecto. El bot efectuará el cambio de mayúsculas a minúsculas (será la misma tarea que comenté en el segundo punto, pero ahora invertida) si tiene que hacer algún otro arreglo en la entrada.

Otra de esas minucias: basándome en WN:ES y otras páginas similares supuse que no colocábamos ningún espacio alrededor de los títulos de las secciones, así que indiqué al bot que los eliminara (=== Título === → ===Título===). Sin embargo, dichos espacios aparecen en la versión actualizada de las plantillas de creación de lemas (p. ej. Plantilla:Plantilla Sustantivo) (también son automáticamente insertados por MediaWiki cada vez que creamos una nueva sección en el Café o en las páginas de discusión). Parece, pues, que su adopción es prácticamente un hecho consumado, pero no lo había reflejado en el código del bot; en un principio voy a actualizarlo para que no los borre o los inserte donde falten. Personalmente, creo que le confieren algo más de legibilidad al wikicódigo, siendo apenas dos bytes más por sección. Un saludo, Peter Bowman (discusión) 16:47 22 ago 2015 (UTC)

Estructura para transliteraciones

Hola en el wikcionario hay muchas transliteraciones, pero no tienen una estructura uniforme, ejemplos: menorah, adam. La documentación sobre la estructura del wikcionario no especifica el formato correcto, ¿Serian tan amables de completar la página de estructura para incluir el formato de una transliteración? De antemano gracias, --201.103.49.25 09:52 24 ago 2015 (UTC)

Tech News: 2015-35

Las noticias técnicas más recientes de la comunidad técnica de Wikimedia. Informa sobre estos cambios a otros usuarios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios recientes

• La opción Página aleatoria ya no regresa páginas de desambiguación. [51]

Problemas

• Se arregló un problema que tuvo el editor visual con las imágenes de verificación. [52]

Cambios esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 25 de agosto. Se instalará en todas las wikis excepto en las wikipedias el 26 de agosto y en las wikipedias el 27 de agosto (calendario).

Reuniones

• Puedes participar en la próxima reunión con el equipo del editor visual el 25 de agosto a las 19:00 (UTC). Durante la reunión podrás decirle a los programadores cuales son los defectos más importantes. Consulta cómo participar.

Noticias técnicas preparadas por embajadores técnicos y publicadas usando un bot • Contribuye • Traduce • Obtén ayuda • Comenta • Suscríbete o cancela tu suscripción.

13:02 24 ago 2015 (UTC)

Tech News: 2015-36

Las noticias técnicas más recientes de la comunidad técnica de Wikimedia. Informa sobre estos cambios a otros usuarios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios recientes

• El editor visual ahora creará un enlace automáticamente al escribir un ISBN, PMID o un RFC. [53][54]
• El editor de enlaces en el editor visual es un poco más ancho. Ahora tiene el mismo ancho que la herramienta para agregar citas automáticamente. [55]
• Los programadores de accesorios ya no podrán usar el módulo compatible con versiones anteriores: ext.visualEditor.viewPageTarget.init. En su lugar deben usar ext.visualEditor.desktopArticleTarget.init. [56]
• Los programadores de accesorios ahora pueden usar mediawiki.ForeignApi para comunicarse entre diferentes wikis de Wikimedia. [57]

Cambios esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 1 de septiembre. Se instalará en todas las wikis excepto en las wikipedias el 2 de septiembre y en las wikipedias el 3 de septiembre (calendario).

Reuniones

• Puedes participar en la próxima reunión con el equipo del editor visual el 1 de septiembre a las 19:00 (UTC). Durante la reunión podrás decirle a los programadores cuales son los defectos más importantes. Consulta cómo participar.

Cambios futuros

• Se harán cambios al API de Wikidata que son cambios incompatibles con la versión anterior. Esto ocurrirá probablemente el 9 de septiembre. [58]

Noticias técnicas preparadas por embajadores técnicos y publicadas usando un bot • Contribuye • Traduce • Obtén ayuda • Comenta • Suscríbete o cancela tu suscripción.

21:36 31 ago 2015 (UTC)

Introducing the Wikimedia public policy site

Hi all,

We are excited to introduce a new Wikimedia Public Policy site. The site includes resources and position statements on access, copyright, censorship, intermediary liability, and privacy. The site explains how good public policy supports the Wikimedia projects, editors, and mission.

Visit the public policy portal: https://policy.wikimedia.org/

Please help translate the statements on Meta Wiki. You can read more on the Wikimedia blog.

Thanks,

Yana and Stephen (Talk) 18:12 2 sep 2015 (UTC)

(Sent with the Global message delivery system)