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 (2026):

Atajo:
WN:C

enero de 2026

Noticias técnicas: 2026-03

Las últimas noticias técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Lo más destacado de la semana

• La Fundación Wikimedia ha compartido algunas preguntas guía para el plan anual entre julio de 2026 y junio de 2027 en Meta y Diff. Estas preguntas se enfocan en las tendencias globales, una experimentación más rápida y saludable, la mejora del soporte a los recién llegados, potenciar a los editores y usuarios avanzados, mejorar la colaboración entre proyectos, y el crecimiento y retención de lectores. Las ideas y comentarios son bienvenidos en la página de discusión.

Actualizaciones para editores

• Como parte del trabajo actual del equipo de Tecnología Comunitaria en el proyecto de múltiples listas de seguimiento, se actualizará la visualización de Editar lista de seguimiento como un primer paso hacia esta funcionalidad. Además, se actualizará la paginación en la búsqueda, como parte del trabajo orientado a renovar la paginación y la navegación de páginas.
• La Lista de seguimiento global es una extensión de MediaWiki que permite consultar las listas de seguimiento de diferentes wikis en una misma página. Se ha actualizado recientemente para asemejarse más a la lista de seguimiento estándar, incluyendo preparativos para las cuentas temporales y el enmascaramiento de IP (como el redireccionamiento de los enlaces de usuario a sus páginas de contribuciones), el uso de negrita en los títulos de página y la apertura de los enlaces de etiquetas y resúmenes de edición en nuevas pestañas del navegador.
• Revisa las 28 tareas enviadas por la comunidad que fueron resueltas la semana pasada. Por ejemplo, se ha solucionado el problema por el que los bloqueos globales no tenían la opción de desactivar el envío de correos electrónicos; esta función estará disponible para su uso durante la semana del 13 de enero.

Actualizaciones para los colaboradores técnicos

• La herramienta de citas del Editor Visual y Vista previa de referencias soportan el tipo de referencia "map".
• Actualizaciones detalladas de código de esta semana: MediaWiki/MediaWiki

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 19:33 12 ene 2026 (UTC)

Thank You for Last Year – Join Wiki Loves Ramadan 2026

Dear Wikimedia communities,

We hope you are doing well, and we wish you a happy New Year.

Last year, we captured light. This year, we’ll capture legacy.

In 2025, communities around the world shared the glow of Ramadan nights and the warmth of collective iftars. In 2026, Wiki Loves Ramadan is expanding, bringing more stories, more cultures, and deeper global connections across Wikimedia projects.

We invite you to explore the Wiki Loves Ramadan 2026 Meta page to learn how you can participate and sign up your community.

📷 Photo campaign on Wikimedia Commons

If you have questions about the project, please refer to the FAQs:

• Meta-Wiki
• Wikimedia Commons

Early registration for updates is now open via the Event page

Stay connected and receive updates:

• Telegram channel
• Mailing list

We look forward to collaborating with you and your community.

The Wiki Loves Ramadan 2026 Organizing Team 19:45 16 ene 2026 (UTC)

Actual

Restringir posiciones para referencias

Feliz año nuevo a todos los contribuyentes! Estoy orgulloso de todo lo que se logró con el formato en estos dos últimos años pero todavía quedan algunos cabos sueltos, así que empezamos el año de la mejor manera intriduciendo una nueva discusión: la posición en la que deben ir las referencias. Actualmente tenemos que "no hay una regla específica acerca de dónde deben ir", pero en la práctica estuve analizando que en realidad suelen ir en los mismos lugares de siempre, que es al final de cada frase: ora en la etimología, en cada definición o en ítems adicionales especificados en Información Adicional. Permitir referencias en otros lugares lo veo contraproducente:

1. Dentro o al lado de las plantillas extratextuales como {{pron-graf}}, {{t}} o las plantillas de ítems dificultará a futuro el parseo, lo que dificultará a su vez las correcciones automáticas que pienso volver a implementar algo de eso más adelante.
2. La pronunciación suele ser regular, implementada con módulo y son pocos los casos en donde se podría disputar. A lo sumo, se disputarían las reglas en las que se basa el módulo, pero para eso existe el subespacio Wikcionario:Referencia, que incluye a las reglas de pronunciación y que podrían ir allí las referencias. En otras palabras, no sirve una referencia para la pronunciación de cada palabra, sino de una (o varias) que expliquen las reglas para transcribir de todo el idioma. Lo mismo con las plantillas de flexión, aunque se podría admitir referencias en el parámetro |nota, para casos particulares como en haber o compungir.
3. Para las definiciones, si hay referencias al final de la oración se asume que abarcan a toda la definición, lo que incluye a los ítems que están debajo, que vienen a ser las etiquetas de uso o ámbito. Si aparece información relevante sobre ello en algún lugar, tiene que figurar la definición también, por lo tanto es coherente mover al final de la oración las etiquetas de referencia que aparecen al lado de las plantillas de ítems.
4. El foco debe estar sobre la entrada que se define, no sobre las entradas enlazadas, pero agregar referencias en traducciones o variantes (esto último dentro de pron-graf) desvía el foco hacia las otras entradas, cuando lo correcto en todo caso sería crearlas y añadir las referencias en dichas páginas.
5. Por último, al final en la sección "Referencias y Notas", tiene el inconveniente de que se pierde precisión porque teniendo en cuenta de que una palabra puede tener muchas acepciones, cómo se puede identificar rápidamente de dónde salieron unas y de dónde las otras? De nuevo, agregando la referencia luego de cada definición. Es tedioso, pero prefiero que así sea si es para evitar confusiones en el futuro, por ejemplo, cuando un usuario quiera añadir al final de la sección otra acepción que la haya encontrado en otro lugar y se olvide de mover las plantillas que estaban en Referencias y Notas (de las que tácitamente se asumía que referenciaban a toda la entrada y ya no lo estarían haciendo). Esto viene a dar respuesta al dilema de si en esa sección deberíamos agregar las referencias antes o después del tag <references />. Mi solución es simple: no agregarlas allí. Por eso le pregunto a @Peter Bowman si, de aplicarse esta nueva política y tras haber hecho las migraciones necesarias, si sería posible también que la sección "Referencias y Notas" se autogenere al final de todo, esto es, para eliminarla de la "estructura oficial" del formato, para así quitar otra duda al resto de editores.

Tmagc (discusión) 04:14 2 ene 2026 (UTC)

¡Feliz año, @Tmagc! Estoy de acuerdo en todos los puntos. Con respecto al quinto, dado que las referencias se autogeneran al final de la página si no se ha añadido un <references/>, teóricamente podríamos eliminar la sección Referencias y notas del wikicódigo de todas las páginas y también generarla dinámicamente (por medio de JavaScript). Sin embargo, estoy viendo que esto requeriría más trabajo en la versión para móviles, en la cual prefiero no ir a contracorriente del diseño oficial de su interfaz. Una solución que se me ocurre es hacer que solo sea obligatoria cuando exista al menos una referencia (como en enwiktionary), evitando mantener esta sección vacía en cientos de miles de entradas. Si recupero la rutina diaria de mi bot con la que revisaba el formato de las entradas, puedo hacer que detecte si en la entrada hay al menos un <ref> y añadir esta sección si es necesario. Igualmente, el bot también podría borrarla si no se usa. Un saludo, Peter Bowman (discusión) 13:27 2 ene 2026 (UTC)

Hola. ¡Feliz año! Creo que casi siempre, en todo, uno no es capaz de predecir un montón de casos medianamente comunes. Como precaución, pienso que siempre debería ser posible poner referencias dentro del texto de la definición. Tal vez también en otros sitios, como la pronunciación (ojalá fuera excepcional). Saludos. Lin linao ¿dime? 15:52 2 ene 2026 (UTC)

Bueno, puesto que pasaron ya dos semanas y no hubo ninguna respuesta, procedo a modificar las normas de estilo actuales. Saludos. Tmagc (discusión) 20:03 16 ene 2026 (UTC)

@Peter Bowman PErdón pero esto es tangencial. Querríamos insertar corchetes para cada número? Por el tipo de contenido que tratamos, difícilmente se pueda confundir con el operador de potencia, pero deberíamos al menos espaciar los números para no confundirlos en caso de que se inserten múltiples referencias contiguas. Tmagc (discusión) 20:11 16 ene 2026 (UTC)

@Tmagc: lo que estamos haciendo en realidad es eliminarlos, porque por defecto deberían aparecer. Nunca he sabido por qué se quitaron, el rastro más temprano data de 2006 en una versión borrada de MediaWiki:Cite reference link. El mecanismo se migró a CSS en 2024 con phab:T370512 y lo mantuve en Especial:Diff/5650328. Aprovecho que lo has mencionado para eliminar esa regla. ¿A alguien le molestan los corchetes? Peter Bowman (discusión) 00:34 17 ene 2026 (UTC)

Instituciones

No hace mucho hubo una discusión sobre los nombres propios, aunque el enfoque estaba puesto en otra cosa. Pues bien, quiero retomar de donde la dejamos pero para discutir cuáles son los nombres relevantes.

1. Para comenzar, mi propuesta ahora radica en eliminar todos los nombres de instituciones, en el sentido más amplio del término. Esto incluiría a las siglas porque asimismo las páginas de siglas y abreviaturas deberían siempre redirigir a los títulos completos. Me refiero a páginas como RAE u OEA. De lo contrario, deberíamos entonces no solo permitir los títulos completos, sino los títulos de al menos todas las academias y de todos los bloques regionales habidos y por haber.
2. Lo de los libros de la Biblia me generó dudas pero ahora me inclino a pensar que son tan arbitrarios como lo sería añadir los del Corán o las obras de Platón o las de Aristóteles.
3. Finalmente lo de los nombres y apellidos no me convence mucho. Creo que propondré en Meta un proyecto nuevo específico para ello, básicamente por el hecho de que no parece aplicar en ellos los conceptos de endónimo y exónimo, y también porque se prestan como una vía para farmear y, en algunos idiomas, para para no agregar las definiciones del respectivo nombre común. Si mi propuesta fracasa, mi voto será por moverlos todos a Translingüistico.

Tmagc (discusión) 22:41 8 ene 2026 (UTC)

Hola, @Tmagc. Tengo alguna duda u observación:

1. ¿A qué te refieres con los bloques regionales? Sobre el ejemplo de RAE, no me tiene sentido crear una entrada para Real Academia Española, pero atendiendo al criterio que presentas, "región administrativa especial" no es una institución, luego convendría acotar los límites para no borrar cosas como URL.
2. Estoy de acuerdo. Para esto tenemos la Wikipedia.
3. Va a ser muy difícil que acepten un proyecto nuevo con esas características, y si acaso podría tardar años. No me cuadra mover los nombres a Translingüístico porque pertenecen a un idioma en concreto, tienen su etimología, flexión, pronunciación, a veces incluso derivados, etc. Si quieres tener un lugar donde aglomerar todas las equivalencias (por no llamarlas traducciones) entre idiomas, esa sería la sección de Traducciones del Español, ya que en Translingüístico no está permitida. En cuanto a los apellidos, estoy entre aplicar el mismo razonamiento (igualmente pueden tener flexión, así como una pronunciación no trivial) o fijar unos mínimos (frecuencia de uso por encima de algún umbral y/o presencia de elementos adicionales en la entrada más allá de un "Apellido español").

Peter Bowman (discusión) 11:25 9 ene 2026 (UTC)

1. me referia a la Real Academia Española y a la Radiodifusión Argentina al Exterior. Esas dos entradas no tendrían mucha relevancia aquí. Las otras dos podrian ir.
2. --
3. Mi idea sería ponerlos en translingüístico, en la etimología explicar el origen (de qué idioma viene) y en todo caso usar {{cognados}} o inventar una plantilla similar para mostrar los equivalentes. El problema de como lo tenemos ahora es que es demasiado restrictivo. Por ejemplo, en Alexander dice que equivale a Alejandro, pero hay mucha gente, al menos acá, que se llama Alexánder y no veo que haya nadie interesado en "traducirlos". Aparte, con tu esquema, solo serviría si todos los nombres tienen un equivalente en español. Pero no sería posible mostrar equivalencias con la caja de traducciones en nombres que existan entre otros idiomas. En cuanto a la flexión, también lo pensé. Pero parece ser más algo "circunstancial" y que depende de cada idioma las reglas que aplicar al nombre. Por ejemplo, si alguien, digamos que de Rusia, viene a vivir a la Argentina y se nacionaliza, su nombre lo va a seguir llevando. Si tiene hijos, probablemente toda su descendencia siga llevando el mismo apellido ruso y eso no signfica que sean rusos ni nada por el estilo. Pero qué reglas hay que aplicar? La declinación obviamente se perdería en ese caso y aunque a algunos les guste mantener la pronunciación original, con el tiempo y el paos de generaciones tiende a naturalizarse al español. Shigemitsu es apellido japonés o inglés. Y si alguien que se llame así emigra a la Argentina, pasa a ser un apellido español?

Tmagc (discusión) 16:53 9 ene 2026 (UTC)

Otro motivo que se me olvidó mencionar es que la mayoría de sitios que albergan nombres o apellidos los catalogan por país o región de origen, y no por idioma. Tmagc (discusión) 16:58 9 ene 2026 (UTC)

Volviendo al punto tercero, me estoy decantando por prescindir de los apellidos por completo. No veo mucho sentido en moverlos a Translingüístico porque ni siquiera tienen traducción/equivalencias, y no deberíamos favorecer artificialmente la grafía latina p. ej. para listar apellidos rusos a riesgo de tener que volver a lidiar con las transliteraciones. En cuanto a los nombres, los dejaría como están, en su sección de idioma correspondiente. Solo en las lenguas eslavas declinarlos bien puede ser una odisea, mención aparte a la identificación correcta de sus hipocorísticos. El que algunos nombres no tengan equivalencias entre idiomas es también motivo para no moverlos a una sección que describe palabras aplicables a cualquier idioma. Peter Bowman (discusión) 17:02 10 ene 2026 (UTC)

Volviendo al punto primero, estoy revisando Categoría:ES:Siglas y no sé qué pensar. Hoy has mandado a borrar AMLO y PRIAN, pero veo más casos parecidos y no podemos aplicar el borrado rápido indiscriminadamente sin discutirlo antes. Por otro lado, aunque la expresión completa que la sigla pretende abreviar no sea de diccionario, no significa que esta sigla no pueda tener su propia entrada. Peter Bowman (discusión) 17:10 10 ene 2026 (UTC)

La mayoría están bien, salvo las que refieren a personas y a organizaciones específicas. Como excepción, podríamos dejar quizá los nombres de los proyectos de esta fundación. Tmagc (discusión) 17:33 10 ene 2026 (UTC)

¿Y... entonces?

Sería perfecto que los nombres y apellidos tuvieran su proyecto, pero por lo pronto se quedan aquí, ¿sin cambios?

Y de las siglas... hay que concretizar que tan "específicas" pueden ser, siento que lo más importante es la globalidad o relevancia, tiene sentido para mí que estén ONU, UNICEF, FMI, OTAN, OEA; pero no tanto UNAM, PAN (partido), INSALUD, AMLO, RAE (Argentina). ¿Que una entidad sea más o menos internacional podría ser suficiente?, p. ej. sí RAE, pero no AML (Academia Mexicana de la Lengua).

Como dice Peter, no todas las siglas deberían redirigir a la entrada del término que abrevian, algunas deben tener la definición directamente y en casos como la RAE solo redirigir a Wikipedia.

Algo de las siglas que no me convence es que tengan su propia categoría gramatical, pues hablamos de sustantivos (los HSH, la URL) y adjetivos (personas LGBTI, las 9 p. m.). Raos10 (discusión) 18:54 13 ene 2026 (UTC)

@Raos10 Conviene tener las siglas en una categoría aparte, la mayoría de ellas debe redirigir a un título no abreviado. Después, para el 99% de los hablantes está más que claro que es posible usar una palabra como si fuera de otra clase gramatical, así se usan adjetivos como sustantivos, adverbios como adjetivos y siglas como sustantivos. Únicamente la RAE piensa que no se puede y por eso se inventa esperpentos como cederrón, devedé, etc. Tmagc (discusión) 05:06 19 ene 2026 (UTC)

Okey, ya lo repensé y creo que me había confundido un poco. En la Guía de estilo se mencionan las plantillas de sección como plantillas que indican la categoría gramatical del término, pero realmente son categorías aceptadas por convención: letra, sufijo, símbolo, refrán, etc.

Bueno, parte de esto es porque considero que nos falta mostrar el género, lo cual sería sencillo si tuvieran la plantilla de sección de sustantivo (y que se categorizaran como siglas desde etimología). Se me haría un poco extraño "Sigla femenina" pero si esa fuera la convención, está bien. Raos10 (discusión) 00:29 20 ene 2026 (UTC)

@Raos10 No tiene sentido mostrar el género porque tampoco flexionan (daría pie para que alguien se confunda e inserte la plantilla de flexión erróneamente). En cuanto al género, se deduce simplemente viendo la propia expansión en la definición. Tmagc (discusión) 01:28 20 ene 2026 (UTC)

Aunque para la gran mayoría de casos sea obvio, habrá excepciones: el/la NN, el LSD (la dietilamida de ácido lisérgico), el AVE (Alta Velocidad Española)...

Y ahora que lo pienso, ¿qué hay de los idiomas que sí flexionan las siglas?

En el inglés se pluralizan como cualquier sustantivo: DVDs, ISBNs, URLs

En el sueco igual tienen todas las flexiones: URL.

¿No deberían tener una plantilla de flexión?, o bueno, solo las siglas que fungan como sustantivos, ignorando siglas como AFAIK, TLDR, etc.

Luego están las siglas fungen como adjetivos comparables: PC (more PC: más políticamente correcto), IQ (como jerga de inteligente), etc.

Ahora tiene menos sentido mantener la sección de sigla, crearía más confusión que hubiera algunas siglas con plantillas de flexión y otras que no. Raos10 (discusión) 18:09 20 ene 2026 (UTC)

@Raos10 Por el contrario, para mí tiene sentido mantener la sección de siglas ya que se puede distinguir criterios por idioma. Por ejemplo, un bot puede detectar y reconocer que son siglas (por la plantilla propia), y de ahí según el idioma agregar o quitar las plantillas de flexión, algo que sería más difícil hacerlo sin esta categoría aparte. No me parece correcto que estén categorizadas como sustantivos esas entradas que mencionás, aunque ese sea su uso más común. Tmagc (discusión) 21:51 20 ene 2026 (UTC)

@Tmagc Mmm, no veo la ventaja, ¿cómo podría un bot, solo con la plantilla de sigla, elegir la plantilla de flexión correcta (sustantivo, adjetivo o frase completa)? Si se categorizaran con la plantilla de sección correspondiente, los bots agregarían las plantillas adecuadas (como con cualquier otra palabra).

Tiene más sentido que, en los idiomas donde sea necesario, se colocara una detección automática en las plantillas de flexión afectadas, por ejemplo que es.sust sea invariante si se detecta que es una sigla (p. ej. todas las letras mayúsculas), y en las excepciones rarísimas (p. ej. ARNm) pues manualmente se agrega inv. O quizá sea más sencillo, quizá un bot podría checar si es sigla por la etimología y ya. Raos10 (discusión) 23:37 20 ene 2026 (UTC)

@Raos10 Siglas son siglas, acrónimos son acrónimos, del mismo modo que locuciones son locuciones. Una posibilidad sería usar los parámetros posicionales de las plantillas de sección para agregar calificadores, algo como {{sigla|es|sustantiva}}, {{sigla|es|adjetiva}}, {{sigla|es|verbal}}. Tmagc (discusión) 05:31 26 ene 2026 (UTC)

Me parece una buena solución, tiene sentido y es consistente con el resto de plantillas. Yo digo que sí se apliquen los parámetros. Raos10 (discusión) 15:37 27 ene 2026 (UTC)

Noticias técnicas: 2026-04

Las últimas noticias técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Actualizaciones para editores

• La barra que se muestra en Especial:Diff en la versión móvil ha sido rediseñada. Ahora permanece oculta por defecto e incorpora un enlace para deshacer al revisar una edición, lo que facilita la tarea a los editores y revisores móviles mientras se mantiene la interfaz despejada.
• La lista de seguimiento global permite consultar las listas de seguimiento de múltiples wikis en una sola página. La extensión sigue mejorando: ahora determina automáticamente la dirección del texto (lo que garantiza la visualización correcta de sitios con nombres de dominio inusuales) y muestra descripciones detalladas de las acciones de los registros. A finales de esta semana, se añadirá un nuevo enlace permanente para la creación de páginas y clases CSS para cada elemento.
• Revisa las 32 tareas enviadas por la comunidad que fueron resueltas la semana pasada. Por ejemplo, se ha solucionado el problema detectado anteriormente en Vector 2022, por el cual el encabezado fijo ocultaba el destino de los enlaces de anclaje.

Actualizaciones para los colaboradores técnicos

• Como se anticipó en el anuncio de deprecación de octubre de 2025, el equipo de Interfaces de MediaWiki comenzará a eliminar de la API REST de MediaWiki todos los puntos finales (endpoints) que terminen en barra diagonal durante la semana del 26 de enero. Se espera que los cambios se implementen en todas las wikis a más tardar el 30 de enero. Se recomienda a todos los usuarios de la API realizar la transición a las versiones sin barra diagonal final. Ambas variantes de cada punto final pueden consultarse, compararse y probarse en la zona de pruebas REST. Si tienes dudas o encuentras algún problema, puedes abrir una tarea en Phabricator en el tablero #MW-Interfaces-Team.
• La documentación interactiva de referencia de la API REST de Wikimedia se ha trasladado. Las solicitudes a la documentación de la API que antes se alojaban a través de RESTBase (por ejemplo: https://en.wikipedia.org/api/rest_v1/) ahora se redireccionan a la zona de pruebas de REST.
• El equipo de la Plataforma de Wikidata de la WMF (WDP) ha publicado su boletín de noticias de enero de 2026. En él se incluyen actualizaciones sobre el cierre del antiguo endpoint del grafo completo, el cambio en la política de User-Agent, las horas de oficina mensuales sobre la migración de Blazegraph y los esfuerzos para reducir las regresiones causadas por el cierre del antiguo endpoint. Como recordatorio, ¡puedes suscribirte al boletín del WDP!
• Actualizaciones detalladas de código de esta semana: MediaWiki

Reuniones y eventos

• La Hackathon de Wikimedia del Noroeste de Europa 2026 se llevará a cabo los días 13 y 14 de marzo en Arnhem, Países Bajos. Las inscripciones se abrieron a mediados de diciembre y cerrarán pronto o cuando se alcance el límite de capacidad. Se trata de un encuentro técnico de dos días que busca reunir a los wikimedistas de la región. ¡Esperamos verte allí!

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 20:29 19 ene 2026 (UTC)

Revisión anual del Código Universal de Conducta y las Directrices de Aplicación

I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 9 February 2026. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Por favor, comparte esta información con otros miembros de tu comunidad en cualquier otro lugar que sea apropiado.

-- In cooperation with the U4C, Keegan (WMF) (talk)

21:02 19 ene 2026 (UTC)

Babel

Hace poco, uno de nuestros usuarios introdujo sus cajas de Babel cuando creó su página. Lo que me lleva a preguntarme: hay un sistema mejor que podría hacerse respecto del actual (por ejemplo crear un nuevo módulo con las leyendas para cada código, en lugar de multiplicar plantillas)? Necesitamos la plantilla {{babel}}? No sería más simple todo haciendo {{#babel:xx|yy|zz|...}}, que es un comando que ya trae MediaWiki por defecto? Tmagc (discusión) 02:41 20 ene 2026 (UTC)

Me parece que {{babel}} debería reimplementarse para que simplemente enmascare una llamada a {{#babel}}, por compatibilidad hacia atrás. Peter Bowman (discusión) 09:03 20 ene 2026 (UTC)

Me gusta más la idea de importar en:Module:Babel, parece una opción más flexible y permite modificar y agregar más idiomas que no trae la extensión #babel por defecto. Además, sería muy fácil migrar todo si creo dos plantillas, tal y como funciona en:Template:Babel, en:Template:Babel userbox. Por el contrario, #babel solamente puede generar tablas, por lo que habrá muchos conflictos o incompatibilidades. Tmagc (discusión) 17:38 20 ene 2026 (UTC)

Noticias técnicas: 2026-05

Las últimas noticias técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Actualizaciones para editores

• La Fundación Wikimedia invita a comentar la propuesta de futuro del Consejo de Producto y Tecnología hasta el 28 de febrero.
• Todos los usuarios con cuentas registradas ya pueden usar llaves de acceso (passkeys) para la autenticación de dos factores (2FA). Las llaves de acceso son una forma sencilla de iniciar sesión sin necesidad de un segundo dispositivo, ya que verifican la identidad mediante huella digital, reconocimiento facial o un código PIN. Para configurar una llave de acceso, primero se debe establecer un método de 2FA convencional. Actualmente, para acceder con una llave de acceso, los usuarios todavía deben introducir su contraseña; sin embargo, a finales de este trimestre, el inicio de sesión sin contraseña permitirá acceder con un solo clic y una llave de acceso. Los usuarios con permisos avanzados también estarán obligados a tener activada la autenticación de dos factores. Esto forma parte del proyecto de Seguridad de cuentas.
• Las personas que no han iniciado sesión y que se encuentran en una IP o rango bloqueado ahora pueden apelar su bloqueo en la wiki mediante la creación de una cuenta temporal, siempre que no se haya marcado la opción «impedir que este usuario edite su propia página de discusión». Esto soluciona el problema de los usuarios que no han iniciado sesión y que necesitan utilizar el procedimiento de desbloqueo a través de su página de discusión de usuario.
• Revisa las 20 tareas enviadas por la comunidad que fueron resueltas la semana pasada. Por ejemplo, se ha actualizado la descripción de los métodos de autenticación de dos factores (2FA) en la página de gestión. Ahora es más clara y fácil de entender para los usuarios, lo que facilita su uso.

Actualizaciones para los colaboradores técnicos

• Se ha añadido una nueva variable al Filtro de abusos, account_type, que ofrece una forma fiable de determinar el tipo de cuenta que se está creando en las acciones createaccount y autocreateaccount. Como parte de este cambio, la variable accountname ha sido renombrada a account_name, por lo que accountname ahora se considera obsoleta. Los gestores de filtros de edición deben actualizar los filtros que utilicen comprobaciones directas del tipo de cuenta o que empleen la variable obsoleta.
• Las miniaturas de imágenes solicitadas en tamaños no estándar, y mediante métodos no convencionales como solicitudes directas a upload.wikimedia.org/…, dejarán de funcionar en un futuro próximo. Este cambio tiene como objetivo evitar el abuso externo persistente por parte de bots y extractores de datos (web-scrapers). Algunos usuarios con CSS/JS personalizados, administradores de interfaz que mantienen accesorios y apariencias locales, así como autores de herramientas, deberán actualizar su código para utilizar tamaños de miniatura estándar. En la tarea están disponibles los detalles, enlaces de búsqueda y ejemplos sobre cómo solucionarlo.
• Actualizaciones detalladas de código de esta semana: MediaWiki

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 21:17 26 ene 2026 (UTC)

Noticias técnicas: 2026-06

Las últimas noticias técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Actualizaciones para editores

• La función "Información de la página", que proporciona información de validación sobre una página (ejemplo), ahora incluye automáticamente una tabla de contenidos. Si existe una página local «MediaWiki:Pageinfo-header» creada por usuarios individuales, ahora puede eliminarse.
• Revisa las 21 tareas enviadas por la comunidad que fueron resueltas la semana pasada. Por ejemplo, el Editor Visual añadía anteriormente formato de negrita o cursiva en las descripciones de los enlaces, lo que complicaba el código wiki (wikitexto). Esto ya se ha solucionado.

Actualizaciones para los colaboradores técnicos

• El 20 de enero no se realizaron copias de seguridad (dumps) de XML. Además, a partir de ahora, estos respaldos se generarán una vez al mes.
• El equipo de Interfaces de MediaWiki ha eliminado el soporte para todos los puntos finales (endpoints) de transformación que contienen una barra diagonal (o slash) al final de la ruta en la API REST de MediaWiki. Se recomienda a todos los usuarios de la API que actualmente utilicen esos puntos finales que realicen la transición a las versiones sin barra diagonal final. Si tiene dudas o encuentra algún problema, abra una tarea en Phabricator en el tablero del equipo de Interfaces de MediaWiki.
• Actualizaciones detalladas de código de esta semana: MediaWiki

Lo más destacado de la semana

• La Fundación Wikimedia ha compartido en Meta y en Diff algunas preguntas guía para el plan anual que abarcará desde julio de 2026 hasta junio de 2027. Estas preguntas se centran en las tendencias globales, la agilización de procesos de experimentación, la mejora del soporte para los recién llegados, el fortalecimiento de las herramientas para editores y usuarios avanzados, la optimización de la colaboración entre proyectos, y el crecimiento y la retención de los lectores. Tus ideas y comentarios son bienvenidos en la página de discusión.

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 17:43 2 feb 2026 (UTC)

Noticias técnicas: 2026-07

Las últimas noticias técnicas desde la comunidad técnica de Wikimedia. Por favor, comenta estos cambios con otros usuarios. No todos los cambios te afectarán. Traducciones en varios idiomas están disponibles.

Actualizaciones para editores

• Los editores registrados que gestionan listas de seguimiento extensas o complejas ya pueden organizar y filtrar sus páginas para mejorar su flujo de trabajo mediante la nueva función de etiquetas de la lista de seguimiento. Al añadir etiquetas personalizadas (por ejemplo: páginas creadas por ti, páginas monitorizadas por vandalismo o páginas de discusión), los usuarios pueden identificar más rápido qué necesita atención, reducir la carga cognitiva y responder de manera más eficiente. Esto mejora la usabilidad de la lista de seguimiento, especialmente para los editores más activos.
• Una nueva función disponible en Especial:Contribuciones muestra las cuentas temporales que probablemente pertenezcan a la misma persona, lo que permite que el patrullaje requiera menos tiempo. Al consultar las contribuciones de una cuenta temporal, los usuarios con acceso a sus direcciones IP podrán ver ahora una vista de las contribuciones de las cuentas temporales relacionadas. Esta función busca todas las IP asociadas a una cuenta temporal determinada dentro del periodo de retención de datos y muestra todas las contribuciones de las cuentas temporales que han utilizado dichas IP. Más información.
• Cuando los editores previsualizan una edición en wikitexto, el cuadro que recuerda que se está viendo una previsualización (ubicado en la parte superior) ahora tiene un fondo gris neutro en lugar del fondo amarillo de advertencia. Esto facilita distinguir el aviso de previsualización de los mensajes de advertencia reales (por ejemplo, conflictos de edición o redirecciones problemáticas), los cuales aparecen en cuadros independientes de advertencia o error.
• La lista de seguimiento global permite consultar las listas de seguimiento de múltiples wikis en una sola página. Se continúan realizando mejoras en la extensión: ahora es compatible con más de un sitio que utilice Wikibase (por ejemplo, tanto Wikidata como testwikidata). Además, se han resuelto los problemas de dirección del texto para los usuarios que prefieren utilizar Wikidata u otros sitios con Wikibase en idiomas que se escriben de derecha a izquierda (RTL).
• Los "enlaces mágicos" automáticos para los números ISBN, RFC y PMID han sido marcados como obsoletos en wikitexto desde 2021 debido a su falta de flexibilidad y a dificultades con la localización. Varias wikis han logrado reemplazar los enlaces mágicos de RFC y PMID con enlaces externos equivalentes, pero a menudo se requería una plantilla para sustituir la funcionalidad del enlace mágico de ISBN. Ahora existe una nueva función del analizador (parser function) integrada, {{#isbn}}, disponible para reemplazar la funcionalidad básica de dichos enlaces. Esto facilita la transición a las wikis que deseen abandonar el uso de la funcionalidad de enlaces mágicos obsoleta.
• Se han creado dos nuevas wikis:
  • una Wikipedia en jju (w:kaj:)
  • una Wikipedia en nawat (w:ppl:)
• Revisa las 23 tareas enviadas por la comunidad que fueron resueltas la semana pasada.

Actualizaciones para los colaboradores técnicos

• Se ha creado un nuevo grupo de usuarios global: Bots locales. El software lo utilizará internamente para permitir que los bots de la comunidad superen los límites aplicados para prevenir el abuso de los extractores de datos (web scrapers). Las cuentas aprobadas como bots en al menos una wiki de Wikimedia se añadirán automáticamente a este grupo. Esto no modifica los permisos actuales del bot.
• Actualizaciones detalladas de código de esta semana: MediaWiki

Reuniones y eventos

• La Conferencia de Primavera de Usuarios y Desarrolladores de MediaWiki 2026 se celebrará del 25 al 27 de marzo en Salt Lake City, Estados Unidos. Este evento está organizado por y para la comunidad de MediaWiki en entornos de terceros. Ya puedes proponer sesiones y registrarte para asistir.

Las Noticias Técnicas son preparadas por los escritores de Noticias Técnicas y publicadas con un bot • Colabore • traduzca • obtenga ayuda • denos su opinión • suscríbase o cancele su suscripción.

MediaWiki message delivery 23:30 9 feb 2026 (UTC)

IMPORTANTE: Revisión de actividad de administradores

Hola. En virtud de un consenso comunitario global, se aprobó en el año 2013 una política que tiene por objeto la retirada de los permisos avanzados (administrador, burócrata, administrador de interfaz, etc.) de aquellas cuentas que se encuentren inactivas. De acuerdo con la misma, los stewards están revisando la actividad de los administradores en todos los proyectos de la Fundación Wikimedia que no dispongan de una política de inactividad propia. Hasta donde sabemos, este wiki no cuenta con un proceso formal ni política relativa a la revisión y retirada de permisos avanzados de cuentas inactivas. Esto significa que los stewards se encargarán de ello de acuerdo con la política de revisión de actividad administrativa.

Hemos determinado que los siguientes usuarios cumplen el criterio de inactividad (sin ediciones ni acciones registradas por más de 2 años consecutivos):

1. User:Alakrano (burócrata, administrador)

Estos usuarios recibirán una notificación pronto, donde se les informará que deben empezar una discusión en la comunidad si quieren mantener algunos o todos sus permisos. Si los usuarios no responden sus permisos serán retirados por los stewards.

Sin embargo, si ustedes como comunidad desean crear su propio proceso de revisión de actividad para sustituir el proceso global, quieren tomar otra decisión acerca de los usuarios inactivos o tienen alguna otra política que se nos pasó por alto, entonces notifiquen a los stewards en Meta-Wiki para que sepamos que no debemos proceder con la revisión de permisos en este wiki.

Gracias, EPIC (discusión) 17:34 14 feb 2026 (UTC)

Revalidación de la administradora Lourdes Cardenal

Buenas! No me gusta ―y creo que a nadie le gusta― ser quien rompa el hielo con estos asuntos, pero por el bien del proyecto tengo el deber de hacerlo. Meta está en época de revalidación de sysops, y en su momento se decidió suscribir a la política global ―que ya dije que es un error, que deberíamos tener la nuestra―. Así que nos llega ahora una notificación con los supuestos administradores inactivos (lo pueden ver en el hilo anterior). Pensé que iban a aparecer más en la lista. Pero no ocurrió, así que nos damos cuenta que por eso nosotros mismos deberíamos revalidar a nuestros administradores en lugar de delegar el proceso a terceros que desconocen completamente la situación del proyecto. En este caso, debido a que:

• La usuaria estuvo prácticamente contribuyendo muy poco después de 2014, cayendo en inactividad total en 2018
• Tras una notificación que le envían en 2021 (supuestamente errónea según el concepto que Meta toma por inactividad), recién aquí, oh casualidad! la usuaria se acuerda de que el proyecto existe y hace un par de contribuciones por un año aproximadamente
• Para volver a caer en inactividad en 2022 y con ausencia definitiva en junio de 2023.
• Luego, envía un mensaje a finales del año pasado, no se si bienintencionada o malintencionadamente, pero lo cierto es que increíblemente bastó para eludir los controles de Meta.
• Y, al margen de si a la usuaria solo le "interesa" el proyecto justo cuando sabe que está a punto de perder sus "privilegios", así y todo no veo por qué la necesitaríamos como administradora. Estuve revisando y corrigiendo varias de sus contribuciones y mi evaluación es que nunca terminó de agarrar del todo el formato de las entradas. Confiesa además que no es buena para los asuntos técnicos, pero tampoco veo grandes hazañas en lo "no técnico". No me malinterpreten: sí hubo épocas en donde combatió al vandalismo, pero eso no necesariamente está relacionado con administrar, existe un flag de reversor.
• Y por si fuera poco, ya ha confesado que quiere abandonar el puesto, pero le pidieron que "se quedara para combatir el vandalismo". Quién le dijo eso? Además, si pasa por ahí, nuevamente para eso está el flag de reversora.

Le pido a @Lourdes Cardenal que renuncie. Si damos los controles de administrador a alguien, es para que administre, no para que solamente ostente la placa en su PU. Y por las dudas: si alguien me salta ahora con que "es efectivo mantenerla como administradora, porque entonces podemos recordarle esto y amenazarla con quitarle los botones cada dos años, para que así vuelva a contribuir, y que es mejor eso a que abandone el sitio de una vez y para siempre", me permito decir que aquí no se trabaja a punta de pistola. Si quiere contribuir, que lo haga como una usuaria normal, con lo que pueda, cuando pueda y como pueda; no necesita mantener el rol de administradora para eso. Tmagc (discusión) 05:17 15 feb 2026 (UTC)