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.

Nueva estructura: plantillas de encabezado

Algo de información previa: mi bot finalizó la primera fase de la transición a finales de septiembre, habiendo procesado la mayoría de las entradas canónicas, como se solían llamar aquí antes; en otras palabras, todas las entradas que no fueran formas flexivas. De un total de 835 000 entradas, esto supuso unas 135 000, de las cuales aprox. 35 000 corresponderían a apellidos (en su mayoría), topónimos y otros antropónimos. Desde hace unas semanas está trabajando con las formas flexivas, previendo acabar esta segunda fase a principios de noviembre. Quedaría por procesar otro grupo numeroso de entradas cuyo tratamiento consultaré en las próximas semanas.

Quería comentar aquí ciertos casos límite que he encontrado al tratar con las antiguas Categoría:Plantillas de encabezado (ahora casi todas en Categoría:Plantillas de encabezado (obsoletas)). De todas ellas, merecen una mención aparte {{INE-ES}}, {{POZ-POL-ES}}, {{Chono-ES}}, {{carácter oriental}}, {{TAXO}}, {{TRANS}} y {{TRANSLIT}}. Peter Bowman (discusión) 18:41 20 oct 2015 (UTC)

{{INE-ES}}, {{POZ-POL-ES}}, {{Chono-ES}}

Su característica en común consiste en que corresponden a lenguas reconstruidas, con ciertas peculiaridades en su estructura y la presencia de un aviso debajo del encabezamiento. Ya he convertido todas las entradas en estos idiomas a la nueva estructura con {{lengua}}, junto con una nueva plantilla que sustituye al aviso anterior, {{reconstruido}}. Aparte de eso:

• Ninguna de ellas contenía información relativa a la pronunciación o a la etimología, de modo que el bot no tratará de añadir {{pron-graf}} ni la sección etimológica por defecto.
• Las entradas del protoindoeuropeo hacen uso de tres secciones adicionales no contempladas en Wikcionario:Estructura: Notación, Evidencias y Otras formas (ver *sōw).
• No parece que haya ningún código ISO establecido para el chono, así que he tenido que crear {{chono}} para que sustituya a la plantilla de código de idioma habitual.

Me llamó la atención el caso de la lengua chono, de la que, según la Wikipedia, solo «se conocen con certeza alrededor de 20 palabras» gracias al único testimonio del idioma que ha perdurado hasta hoy: s:Doctrina para los viejos chonos. De momento, las únicas entradas que contiene el Wikcionario son cot y sap, siendo básicamente un extracto de dicho documento en ambos casos. Si podemos aportar tan poco acerca de este idioma, ¿tiene sentido incluirlo en el Wikcionario? (ping Lin linao). Peter Bowman (discusión) 18:41 20 oct 2015 (UTC)

Hola. No hay código ISO para el chono, porque Ethnologue y ISO-639 trabajan principalmente con lenguas vivas. SIL tenía un código para el Kakauhua (un invento de ellos, basado en el chono, el no documentado caucahué y el kawésqar), pero lo borraron al darse cuenta. A mí me parece que sí tiene sentido crear entradas para lenguas así, por la lengua en sí misma y por su interés en el estudio de las lenguas americanas en general y de las de la Patagonia y el mapudungun en especial. El chono es casi un "fantasma", que hasta la publicación de ese catecismo solo se conocía por deducciones de toponimia bastante discutibles (según eso Linlinao son "dos cerros y una bahía protegida del viento del norueste") y había un vocabulario falso de la década de 1930 y se especula(ba) con que es un dialecto del kawésqar. Es bastante difícil hallar materiales sobre lenguas así y creo que es un aporte que el Wikcionario organice las pocas palabras que se conocen de ellas, por ejemplo, también me gustaría crear entradas para los números de la lengua de Magdalena de Cao Viejo. Saludos. Lin linao ¿dime? 19:50 20 oct 2015 (UTC)

• chono: concuerdo en guardar las pocas palabras preservadas. y mientras no se defina un código oficialmente también me parece bien que usemos un código especial en wikcionario, es decir "chono" está bien ("glottocode" chon1248 en glottolog.org).
• el código poz-pol hay que cambiarlo, poz ISO 639-3 de lenguas malayo-polinesias + pol polaco. (podríamos usar poz con alguna especificación)
• el protoindoeuropeo y en general todas las lenguas reconstruidas van a variar en dependencia al tiempo y a los autores... *sōw es un buen ejemplo de un mal ejemplo:

1. está basada en trabajos de Starostin (sus teorías van a serles muy interesantes a "indogermanistas" avanzados, pero en general su obra es demasiado especulativa)

2. parece estar mal interpretada, significa solo "parir". "hijo" se deriva con una "n" en la segunda sílaba (se entiende el error en la transcripción a wikcionario, ya que no está bien aclarado en la página de referencia)

Etimología en muchos casos sí se debería usar (ver, por ejemplo *dwi(h₁)dḱm̥ti)

Pronunciación ver Notación.

Notación sería información fonológica que iría dentro de pron-graf con fono=, así *sōw se daría /soːw/. incógnitas (como las laringales h₁, h₂, h₃) requerirían notas (volviendo a la necesidad de notas para los parámetros fono/fone).

Evidencias es lo que ya hacemos en otras lenguas bajo el apartado "Información adicional" con {{derivados|des=x}}...{{centro}}...{{abajo}} que genera la tabla "Descendientes de XXX en otras lenguas" (está mejor equipada que la que se empleó en *sōw). pero teniendo en cuenta la importancia de esta información para este tipo de entradas no deberíamos tratarla de "adicional". el apartado "Evidencias" no está mal, pero con la tabla {{derivados}}, yo preferiría "Descendientes", que podemos poner a voto en algún momento.

Otras formas: hasta ahora evité crear entradas de reconstrucciones por este tema... que hay muchas alternativas, en parte distintas representaciones de la misma (o casi la misma) fonología, pero en tantas otras se trata de reconstrucciones distintas basadas en innovaciones, ideas distintas, etc.

pero en correlación a otras entradas debería ir cercano a variantes/grafías alternativas dentro de pron-graf

(perdón, por tormentas se me cortó varias veces la luz obligándome a reescribir este texto varias veces. en parte había quedado grabado el texto en otras partes perdí el hilo... espero que más o menos se entienda igual) --Ninud (discusión) 14:11 11 nov 2015 (UTC)

Orden de los encabezamientos

(En unas horas expondré mis dudas. Van a cumplirse tres semanas desde la última firma y todavía no quiero que el bot archive este hilo. Peter Bowman (discusión) 15:05 10 nov 2015 (UTC))

(Ninud: he trasladado tus comentarios a la sección anterior. Un saludo, Peter Bowman (discusión) 15:53 11 nov 2015 (UTC))

Quería proponer un orden para los encabezamientos especiales, a saber, los símbolos (entre otros) translingüísticos ({{TRANS}}), las denominaciones taxonómicas ({{TAXO}}) y los caracteres orientales ({{Carácter oriental}}). La propuesta sería seguir un esquema como este:

• translingüístico/denominación taxonómica/caracter oriental
• español
• otros idiomas
• transliteraciones
• referencias y notas

Esos tres encabezamientos irían siempre antes que las demás secciones. Los he incluido en la misma línea por cierta similitud entre ellos (símbolos/letras/códigos/etc. no adscritos a ningún idioma en concreto) y la poca probabilidad de que coincidan dos o más en una misma entrada, pero aún así el orden sería el arriba presentado para tal hipotético caso. La elección de colocarlos en primera posición viene de la costumbre, observando soluciones parecidas en otros proyectos, y de seguir con el esquema ya adoptado en los caracteres orientales, cuyas entradas normalmente preceden a las del mandarín en caso de coincidir en una misma página. Un saludo, Peter Bowman (discusión) 22:09 18 nov 2015 (UTC)

me parece bien, no se me ocurren inconvenientes (excepto tal vez alguna discusión sobre el trato de formas oficiales como el hanyu pinyin para el mandarín, o las variantes romanj para el japonés, etc.) --Ninud (discusión) 10:26 19 nov 2015 (UTC)

Creo que esas variantes ya están siendo tratadas adecuadamente, por ejemplo tenemos inu#ja y 二月#ja, con el parámetro escritura de {{lengua}} tomando los valores romaji y kanji, respectivamente. Solo habría que corregir los casos donde dicha información fue introducida erróneamente en el encabezamiento de idioma, después llevada por el bot al parámetro alt de {{pron-graf}}: hi#ja, kama#ja, naifu#ja, rekkon#ja, sugoi#ja, umi#ja, un#ja. Un saludo, Peter Bowman (discusión) 13:55 19 nov 2015 (UTC)

ya veo, más o menos como está en たっきゅう/takkyū.

deberíamos integrar la tabla {{escritura-ja}} dentro de {{pron-graf}} con un formato más general que sirva para otras lenguas también (similar a grafías alternativas) --Ninud (discusión) 11:12 20 nov 2015 (UTC)

Hecho, ver 卓球 / たっきゅう / takkyū (el tipo de escritura hay que incluirlo manualmente dentro del parámetro enota=). --Ninud (discusión) 11:41 20 nov 2015 (UTC)

Son 520 páginas, pasaré a convertirlas con el bot dentro de unos días si nadie se opone. Hay un parámetro para la llamada forma mixta, básicamente es uno o más caracteres kanji con la okurigana, si no me equivoco (ver ari o taberu). ¿Debería indicar alguna nota especial, o lo dejo en kanji? Un saludo, Peter Bowman (discusión) 19:43 26 nov 2015 (UTC)

Hecho. Decidí dejar lo de la forma mixta para no alterar la organización de las entradas. Aproveché para añadir la mayoría de los parámetros escritura faltantes, ver Categoría:JA:Escrituras (observación: tal vez forma mixta sea una mejor elección que, simplemente, mixta). También he revisado las entradas mencionadas más arriba (con alt=Romaji) y un puñado en las que aparecía el parámetro transliteración en {{pron-graf}}. Un saludo, Peter Bowman (discusión) 00:02 10 dic 2015 (UTC)

{{TRANSLIT}}

Para las transliteraciones tenía pensado crear una plantilla de encabezamiento nueva, {{translit}}, y requerir esta vez no el nombre completo del idioma, sino su código ISO correspondiente para asemejarse más a {{lengua}}. Extraje la siguiente lista con el número de transliteraciones por idioma y el código indicado en WN:CI: Usuario:PBbot/TRANSLIT. Tal vez queramos renombrar las categorías para asemejarse más, nuevamente, al esquema de los códigos de idioma, pasando del Categoría:Transliteraciones del guyaratí actual a algo como Categoría:GU:Transliteraciones (Categoría:Transliteraciones). Sería más fácil operar con ellas con la nueva plantilla.

Ahora la estructura de estas entradas: ¿qué elementos hacen falta? Parece que lo más habitual es aportar la grafía original (llamada a veces grafía alternativa), la traducción de la acepción y su categoría gramatical, ver ghoḍo. En elohim vemos que han completado la entrada con la misma información adicional que la escritura original, e incluso añadiendo una acepción más. En papirós se indica además la etimología y la flexión, pero esta última referida a la grafía del alfabeto hebreo.

Mi primera propuesta es continuar con la idea de las secciones de transliteraciones (usando ahora la nueva plantilla), pero con el mínimo contenido posible, partiendo de la suposición de que no son más que una redirección blanda como las variantes o grafías alternativas, aunque con incluso menos información propia. El problema es que, aun si se constatara que realmente no hay ninguna información adicional que se pueda aportar, siempre quedaría el encabezamiento de la categoría gramatical (en los ejemplos anteriores, Sustantivo y Sustantivo masculino). Si se diera el caso de que dicha transliteración corresponde a más de una categoría gramatical, tal vez a una forma flexiva, por consistencia habría que crear sendos apartados con la misma redirección apuntando a la grafía original, lo que me parece redundante.

Mi segunda propuesta consiste en dedicar un apartado de segundo nivel para todas las transliteraciones y, dentro del mismo, colocar cada una como elementos de una lista no numerada:

== {{lengua|es}} ==
...

== {{lengua|xx}} ==
...

== Transliteraciones ==
* {{translit|gu|ઘોડો}}.
* {{translit|he|פאפירוס}}.
...

== Referencias y notas ==

Estos elementos seguirían un orden alfabético respecto del nombre de cada idioma. Un saludo, Peter Bowman (discusión) 21:48 26 nov 2015 (UTC)

Mi tercera propuesta, disfrazada de pregunta: ¿por qué dedicarle una entrada a cada transliteración? ¿Tiene sentido crear estas secciones? Completar el Wikcionario con todas las transliteraciones posibles requeriría un esfuerzo titánico y posiblemente inútil, pues ya vemos en los ejemplos anteriores que no es más que repetir la misma información de la grafía original (a no ser que me olvide de algo importante). En estas últimas entradas ni siquiera haría falta aportar la transliteración manualmente, pues se le podría indicar a pron-graf o a la plantilla correspondiente que la genere a partir del título de la página. En el futuro seguramente se podrá extraer esta misma información de Wikidata. Peter Bowman (discusión) 22:00 26 nov 2015 (UTC)

la duda es válida. tal vez sería mejor limitar las entradas de transliteraciones a aquellas lenguas muertas que ya la lingüística moderna trata de forma transliterada (hitita, sumerio, etc.). el resto se podría transliterar dentro de la entrada principal (incluyendo tablas de flexiones).

por otro lado, y lo único que olvidás, es que poder contar con las transliteraciones facilita cualquier tipo de comparación que quiera hacer el usuario, por ejemplo con búsquedas del tipo *f*b*

Excurso: sería muy difícil agregarle parámetros al buscador? por ejemplo V=vocal cualquiera, para limitar la búsqueda a una raíz *fVb* (con una vocal entre f y b) o *fVVb* (vocal o diptongo).

--Ninud (discusión) 11:48 28 nov 2015 (UTC)

En teoría podrías usar expresiones regulares para afinar la búsqueda: mw:Help:CirrusSearch (aunque yo lo he intentado sin éxito, tal vez hayan configurado algunas reglas especiales). De todos modos, ¿cómo sería esa comparación? Tal vez sea más conveniente buscar otros medios (un gadget, listas actualizadas periódicamente) para evitar crear tantas entradas/redirecciones. Peter Bowman (discusión) 18:24 29 nov 2015 (UTC)

Y tengo otra duda :). Respecto a la entrada Yehoshua:

• ¿Es correcto usar la mayúscula inicial en una transliteración? Nunca había visto esto antes, tampoco le encuentro el motivo en este caso.
• ¿Es posible que una misma transliteración coincida para dos o más vocalizaciones diferentes de un lema en hebreo, árabe, yídish...?

Un saludo, Peter Bowman (discusión) 22:06 26 nov 2015 (UTC)

A la primera pregunta, sí, al menos en el caso de que en el sistema de escritura de origen se empleen mayúsculas (alfabeto cirílico y griego). Yo también las usaría en Yehoshua o Nihon u otras cosas que en castellano irían con mayúscula, pero no tengo argumentos técnicos. A la segunda, sí, pasa mucho en japonés, hay menos de 200 sílabas posibles y muchas raíces son homófonas, sobre todo las de origen chino. Así, puede haber un montón de caracteres chinos que en japonés se lean "shi" o "sen". Saludos. Lin linao ¿dime? 00:56 27 nov 2015 (UTC)

En el alfabeto hebreo no existe la distinción minúscula/mayúscula. De todos modos, estoy mirando algunas tablas de transliteración de lenguas eslavas y creo que me equivoqué en mi aseveración del primer punto, no sé por qué estaba tan convencido. En el segundo punto tenía en mente el caso de los alfabetos consonánticos, en los que, por lo general, no se usan las vocales (ver w:Abyad). Estas vienen representadas por diacríticos; por ejemplo, en aquella entrada tenemos יהושע y יְהוֹשֻׁעַ, aparentemente la primera palabra sin vocalizar. Tal vez sea un error, de lo contrario no entiendo qué función cumple ahí la grafía alternativa Yeshua. Un saludo, Peter Bowman (discusión) 02:41 27 nov 2015 (UTC)

{{TRANS}}

Estas secciones pasarían a usar la nueva plantilla {{lengua}} con el pseudocódigo {{trans}}, situándose en primer lugar en la secuencia de encabezamientos de idioma de una entrada (ver #Orden de los encabezamientos). Dudas:

• ¿Debería incluir una sección de etimología por defecto? Algunas entradas merecen un comentario en este apartado (Ag, $...), otras probablemente no (de#Translingüístico, XD...). ¿Hacemos que esta sección sea facultativa? Es decir, no incluirla por defecto cuando realice la conversión a {{lengua}}, borrarla si está vacía, pero permitirles a los editores que añadan una si consideran que se puede aportar información al respecto.
• Pronunciación: no se me ocurre ningún caso en el que sea sensato incorporarla, y aquellas entradas que ya la indican probablemente tengan que prescindir de ella (ver g#Translingüístico, o el curioso caso de Ca). ¿Debería incluir una plantilla {{pron-graf}} por defecto, con el parámetro pron=no? El resultado no es muy estético si no hay más datos que mostrar, pruébese en Especial:Sustituir plantillas. Sí que podría usarla cuando aparecen otros parámetros, p. ej. el de las variantes para un caso a priori poco frecuente como el de H2O.

Un saludo, Peter Bowman (discusión) 00:21 13 dic 2015 (UTC)

Si nadie protesta, en un par de días aplicaré la propuesta anterior y convertiré las entradas translingüísticas. Me ha surgido una pequeña duda al observar que estas páginas están categorizadas actualmente bajo Categoría:Translingüísticos, pero {{lengua}} resuelve automáticamente el nombre a Categoría:Translingüístico-Español. Sopesaré si merece la pena introducir una excepción en el código de la plantilla. Nota: acabo de observar que las denominaciones taxonómicas aparecen como una subcategoría de los translingüísticos. Un saludo, Peter Bowman (discusión) 01:38 19 dic 2015 (UTC)

no es tan importante, pero si necesitas un argumento para ahorrarte un trabajo: como se trata cuasi de una lengua aparte Categoría:Translingüístico-Español me parece la mejor opción. --Ninud (discusión) 10:04 19 dic 2015 (UTC)

Hecho, aunque no estaría mal revisar esas entradas en busca de incongruencias, como la pronunciación que ya he mencionado o la mezcla de símbolos translingüísticos con su lectura en español (ver antónimos en +), así como la de artificios referidos (presuntamente) a un único idioma con un símbolo universal, tal como lo he intentado resolver aquí. Un saludo, Peter Bowman (discusión) 22:12 21 dic 2015 (UTC)

Formas flexivas

hasta ahora la idea era de acomodar las formas flexivas en un apartado al final de la lengua, incluyendo solo la acepción (información flexiva, como género, tiempo, persona, etc.) e información que no figurase en la entrada principal (como pronunciación y ocasionalmente variantes o grafías alternativas).

dudas aparecen dentro de entradas que incluyen en una misma lengua lemas y formas flexivas,

con etimologías distintas:

1. donde el o los lemas y la o las formas flexivas parten de raíces distintas (sal, gana, etc.)

2. donde parten de la misma raíz pero de derivaciones distintas (multa, abusus, abuso, etc.)

con etimologías iguales:

3. como ocurre dentro de tantas lenguas indoeuropeas, por ejemplo, entre las formas base de formas verbales no personales (mayormente participios) y adjetivos o sustantivos (conocido: (g)nōtus, known, bekannt, etc.)

la solución más simple (especialmente para el bot) sería de tratarlas a todas de la misma manera:

• formas flexivas en un apartado al final de la lengua con el título al mismo nivel que las etimologías de los lemas.

la alternativa:

• hacer una excepción para el punto 3, para las formas base de los participios (como se ve en otros proyectos, como wikcionario inglés, aunque irregular y/o inconsecuentemente)

si vamos a optar por un trato excepcional, es decir, poner las formas flexivas y los lemas bajo una misma etimología:

• ¿las ponemos después de los adjetivos y/o sustantivos (como en known)?
• o ¿seguimos el orden lógico? poniendo la forma original, la forma verbal arriba de todo (como ya se puede encontrar esporádicamente dentro de nuestro proyecto, ver sleeping), (y lógicamente para estos casos especiales habría que considerar el título "Participio" en lugar de "Forma verbal").

argumentos en contra de un trato diferenciado:

• el más importante, y bastante contundente, es que vamos a tener que hacer todos los cambios manualmente. dudo mucho que un bot sea capaz de diferenciar entre los puntos 1, 2 y 3... de hecho, hasta a autores experimentados no le resulta fácil (al no contar con el 100% de las etimologías de los lemas... ver objeto, la forma verbal tiene otra etimología que el sustantivo)

conclusión: si tratamos a todas las formas flexivas indiscriminadamente nos vamos a ahorrar muchísimo trabajo!
antes de poner esto a voto, ¿a alguien se le ocurre algo que no tuve en cuenta? tal vez algún argumento en favor de tratarlas diferenciadamente? --Ninud (discusión) 14:24 21 nov 2015 (UTC)

• Ninud, tan solo una pregunta en cuanto al trato indiscriminado: ahora mismo todas las acepciones bajo una misma etimología siguen una numeración continua, incluso cuando hay más de una categoría gramatical (ver conocido). En amica, en cambio, has reiniciado la cuenta para la forma verbal (respecto de la forma adjetiva). ¿Esto debe ser así?

Una costumbre previa al revivido título "Forma flexiva" (satura, multa, multo, etc.). me imagino que ahora se podría enumerar también de forma continua. lo que resulte más intuitivo a los editores... --Ninud (discusión) 10:10 27 nov 2015 (UTC)

• Y una observación mía algo fuera de tema: en amica vemos un índice de contenidos parcialmente plegado debido a la configuración actual del gadget, que es básicamente la misma que en el Wikcionario francés, de donde se tomó el código. Está ajustado para mostrar solo hasta el primer subnivel de la primera sección de la entrada, pero me parece que esto actúa en detrimento de nuestra estructura, ocultándole al lector la organización de las entradas, máxime ahora que estamos ramificando más y más las secciones. ¿Y si mostrara la primera sección completamente desplegada (la del italiano para el ejemplo indicado), y cada vez que se pulse el signo [+] para desplegar una sección de idioma (digamos que el latín para el mismo ejemplo) también mostrara todas las subsecciones desplegadas en vez de tener que ir abriéndolas una por una? Un saludo, Peter Bowman (discusión) 18:26 26 nov 2015 (UTC)

Buena idea! otra cosa que ayudaría es de cambiar los símbolos "+, -, x" por símbolos más llamativos "⊳, ∇, ⊲" (abrir, abierto/cerrar, no se puede abrir más), de hecho el último símbolo se podría omitir, y dejar solo los primeros dos (así funciona el archive manager que uso yo) --Ninud (discusión) 10:32 27 nov 2015 (UTC)

Ninud: ya he aplicado la idea de las secciones desplegadas por defecto (plegando solo las de primer nivel, salvo la primera). Me parece bien cambiar los símbolos, por consistencia propondría usar los mismos triángulos que utilizan Especial:ÁrbolDeCategorías y las páginas Categoría: para mostrar sus subniveles. He preparado un esbozo en Especial:PermaLink/3771333. Si quito el tercer botón se estropearía la sangría de los títulos; tal vez se vea mejor así, de color gris. Un saludo, Peter Bowman (discusión) 19:48 2 dic 2015 (UTC)

pensaba en espacios libres, pero el cambio de color funciona muy bien.

y ahora que lo veo en un ejemplo, los triángulos definitivamente cumplen el objetivo de llamar más la atención ^^ --Ninud (discusión) 10:57 3 dic 2015 (UTC)

Hecho: Especial:Diff/3771323/3772651, Especial:Diff/2635460/3772664. Mala noticia: un mes después de haber creado este gadget, dejó de funcionar correctamente en Chrome (los elementos de la tabla de contenidos quedaron descolocados) a causa de este cambio en el código de MediaWiki. No me di cuenta porque siempre uso Firefox, nadie notificó del fallo :(. Lo menciono como autorreflexión para incentivar revisiones periódicas que puedan evitar estos problemas en el futuro. Un saludo, Peter Bowman (discusión) 23:40 7 dic 2015 (UTC)

se ve muy bien! :)

sobre google chrome y otros browsers: sospecho que la mayoría de nosotros usamos firefox. ayer por casualidad me conecté con un iexplorer y me sorprendió lo distinto que se ve todo... --Ninud (discusión) 10:00 8 dic 2015 (UTC)

¡Ah! Olvidé mencionar otra idea: añadir un botón al lado de Contenido [mostrar/ocultar] para plegar y desplegar todos los elementos a la vez. Borrador: Especial:PermaLink/3772754. Detalles (propuesta):

• Añadir un cajetín (por llamarlo de alguna manera) adicional con dos botones: ► = plegar todo, ▼ = desplegar todo.
• Mostrar dicho cajetín únicamente cuando la tabla de contenidos está desplegada (el usuario ha pulsado el botón [mostrar]).
• Usar triángulos en lugar de texto para no ocupar demasiado espacio; el usuario debería adivinar rápidamente, por analogía, qué función cumple cada uno.
• Si todas las secciones en la tabla de contenidos han sido plegadas o desplegadas, desactivar el botón correspondiente y cambiarle el color a gris.

Un saludo, Peter Bowman (discusión) 15:17 8 dic 2015 (UTC)

de acuerdo :) --Ninud (discusión) 10:34 9 dic 2015 (UTC)

Hecho. No se mostrará el cajetín si no hay ninguna sección que se pueda expandir (también podría suprimirlo si solo hay una sección, o todas son de primer nivel; lo pensaré). El botón ▼ de este cajetín se desactiva si no hay ninguna sección visible desplegada (pero podría haber alguna oculta en los niveles inferiores). Un saludo, Peter Bowman (discusión) 00:32 18 dic 2015 (UTC)

Vale, al final lo he configurado para que no genere ese cajetín si solo hay una sección plegable :). Peter Bowman (discusión) 23:03 18 dic 2015 (UTC)

• Para cuando algún lema parta de una forma flexiva especificada en la misma entrada, p. ej. en el caso de los participios, se podría colocar {{ancla|título_del_ancla}} bajo el título Forma flexiva y después añadir algo como Del [[#título_del_ancla|participio]] de XX. en la etimología de dicho lema. Aunque yo preferiría crear una plantilla de sección {{forma flexiva}} que admita como parámetro el código de idioma, para mantener un formato único (al final cada editor acabaría poniendo el ancla en cualquier lado), con la posibilidad de añadir especializaciones para cada tipo de forma. Esto enlazaría en cierto modo con el hilo #Entradas de adjetivos / participios perfectos. Un saludo, Peter Bowman (discusión) 18:57 26 nov 2015 (UTC)

  No me había dado cuenta de que esta plantilla ya existía :). Parece ser un trabajo dejado a medias, comentado con más detalle aquí: WN:Café/2014 03#Plantilla forma flexiva. Creo que se podría reusar. Peter Bowman (discusión) 19:04 26 nov 2015 (UTC)

No estoy seguro si entendí bien. ¿se pondría el ancla en la forma flexiva (en este caso en la forma base del participio) y luego en la etimología del adjetivo o sustantivo un link hacia el ancla? --Ninud (discusión) 10:52 27 nov 2015 (UTC)

Exacto. En la propuesta de la plantilla se trataría de usar === {{forma flexiva|xx}} === para crear un ancla llamado, digamos, #flex-xx, y luego enlazarlo desde la etimología con [[#flex-xx|texto del enlace]], manualmente o por medio de {{etimología}}. La razón de generar un ancla nueva en lugar de usar #Forma_flexiva es porque esta última no funcionará bien si en la entrada hay más de una sección con ese nombre. Peter Bowman (discusión) 21:00 27 nov 2015 (UTC)

ah, ahora entendí bien el motivo. buena idea :) --Ninud (discusión) 10:24 28 nov 2015 (UTC)

Voto

sobre entradas con lemas y formas flexivas en una misma lengua:
tratar las formas flexivas indiscriminadamente. es decir, pasarlas a un apartado al final de la lengua bajo el título "Forma flexiva", no solo cuando difieran de los lemas en sus etimologías, sino también cuando tengan la misma etimología (en su gran mayoría participios y adjetivos y/o sustantivos, aunque no siempre, comparar la estructura antigua en amiga vs. el trato indiferenciado en amica en italiano). --Ninud (discusión) 11:20 25 nov 2015 (UTC)

1. A favor, simplificará muchísimo la labor al bot y a nosotros. --Ninud (discusión) 11:20 25 nov 2015 (UTC)
2. A favor. Peter Bowman (discusión) 18:27 26 nov 2015 (UTC)
3. A favor, pareciera ser el mal menor. Lin linao ¿dime? 17:24 27 nov 2015 (UTC)

Anotaciones y categorías en formas flexivas

Actualmente, unas 650 000 páginas ya han sido convertidas a la nueva estructura. El resto son, en su mayor parte, formas flexivas en las que aparece al menos una plantilla {{anotación}} no vacía. Parece ser que el propósito de esta es facilitar la creación de entradas mediante bot (Categoría:Wikcionario:Plantillas Bot) de modo que, a través de una serie de parámetros, es posible especificar el ámbito de uso, los parónimos, variantes, etc., siendo más flexible en este sentido que las correspondientes plantillas {{ámbito}}, {{parónimo}}, {{variantes}}... Hace algunas semanas extraje el número de páginas donde se usa esta plantilla en función del título de la anotación:

• +62k para Uso, habitualmente formas del futuro de subjuntivo como tuviere, con la anotación anticuado
• +82k para una Variante del pretérito imperfecto de subjuntivo (tuviera, tuviese) en conjunción con Parónimo
• apenas un puñado para Ámbito (garantes) y Sinónimo (pluguieron)

El procedimiento que he seguido ha sido de borrar las plantillas {{anotación}} vacías (son meros residuos de la acción de un bot) y convertir las demás, por un lado, a plantillas {{uso}}, y por otro, a parámetros de {{pron-graf}} (parónimos y variantes). El problema que surgió es que estas dos últimas categorizan automáticamente la página en Categoría:ES:Términos anticuados y Categoría:ES:Variantes, respectivamente y para el caso particular del español. Obviamente, tras la conversión ambas se llenarían con formas flexivas y serían prácticamente inútiles, de modo que decidí omitir estas entradas. La idea que quiero proponer aquí es la introducción de un parámetro nuevo en estas plantillas para indicarles que no categoricen la entrada (o que usen una categoría designada específicamente para las formas flexivas). Sería algo así:

• para {{uso}}: {{uso|anticuado|flex=x}} (cualquier valor distinto de una cadena vacía)
• para {{pron-graf}}: {{pron-graf|...|tipo=flex}}

El parámetro tipo en el último caso acogería también otra clase de entradas de tratamiento especial; aprovecho para adelantar la idea de introducir tipo=taxo en las denominaciones taxonómicas (antigua plantilla {{TAXO}}), lo que indicaría a {{pron-graf}} que debe mostrar el título de la entrada en cursiva. Un saludo, Peter Bowman (discusión) 23:33 24 nov 2015 (UTC)

Fuera de tema, creo que la forma verbal "(tú) garantes" no existe en la vida real, aunque sea téoricamente posible: por lo que dice la nota, el verbo no es defectivo en Argentina y Uruguay, pero allí no se conjuga con tuteo, así que solo se diría "(vos) garantís". Saludos. Lin linao ¿dime? 03:10 25 nov 2015 (UTC)

A mí me parece una buena solución para no saturar esas categorías. A lo mejor una «Categoría:ES:Términos anticuados:Futuro de subjuntivo» y una «Categoría:ES:Variantes:Pretérito de subjuntivo» podrían resultar útiles si se decidiese mantener la categorización de las formas flexivas, aunque no sé si tiene mucho sentido o utilidad. Por otra parte, quería llamar la atención sobre el asunto de los parónimos. ¿Es adecuado que —como sucede en prácticamente todos los verbos— aparezca comiere como parónimo de comiera, por ejemplo? Lo pregunto porque en WN:ES especifica que «no está pensado para enumerar todas las palabras que se parezcan», sino para evitar posibles confusiones entre palabras... y no sé qué margen de confusión puede haber entre comiera y comiere teniendo en cuenta que su pronunciación es bastante diferente y que la segunda no se usa en la lengua hablada casi nunca. Saludos, -- Saul ip Allô ? 10:58 26 nov 2015 (UTC)

Una explicación con la que me suelo encontrar en otro proyecto es que este tipo de información podría resultarle de utilidad a lectores con una lengua materna diferente, o también para personas que estén aprendiendo el idioma. Siguiendo este razonamiento, yo estaría en desacuerdo con el ejemplo que se indica en WN:ES para las palabras perro y pero, en el que se desaconseja indicar la paronimia. Lo mismo con respecto a comiera y comiere: no creo que la pronunciación sea tan diferente (una sola vocal en posición átona), y precisamente por el hecho de que aún se documente comiere con un uso equivalente al pretérito imperfecto de subjuntivo ([21]), una breve indicación como la de la paronimia ayudaría a distinguir la forma obsoleta de la que se usa en la actualidad. Añadiría, si se decidiera dejar esta indicación en las formas del tipo comiera, que sería conveniente hacer lo mismo en las formas tipo comiere para conservar la simetría. Además, la cualidad de parónimo no se refiere solamente al parecido en el sonido, sino también en la forma (escrita): [22]. Un saludo, Peter Bowman (discusión) 16:04 26 nov 2015 (UTC)

El «pero» que me surge a mí es... ¿cuál será el criterio entonces para incluir una palabra como parónima de otra? Quiero decir, llevando el razonamiento hasta el extremo, las secciones de «parónimos» y «pares mínimos» podrían ser la misma, porque los pares mínimos solo se diferencian en un sonido... llevando a listas de parónimos larguísimas y, ahora sí, poco útiles. No sé, no me acabo de convencer —aunque veo tu argumentación y también me tiene sentido...—. Saludos, -- Saul ip Allô ? 15:18 30 nov 2015 (UTC)

Ahora yo también estoy confuso :(. Acabo de advertir que, según nuestras definiciones de par mínimo y parónimo, los pares mínimos no son más que casos especiales de paronimia, de modo que, como indicas, podríamos prescindir de los primeros y sí, construir listas de parónimos absurdamente largas. Ahora mismo, los pares mínimos se detallan en Información adicional junto con los anagramas, pensaba dedicarles una plantilla nueva. ¿Y si lleváramos todos los parónimos a esta sección, reviviendo la plantilla {{parónimo}} (ahora integrada en {{pron-graf}}), y fusionándolos con los pares mínimos?

Un poco fuera de tema: me temo que el sistema actual no está preparado para aceptar listas de parámetros realmente largas. Véase el wikicódigo de iluec. Para que esto tenga sentido, pron-graf debería volver a ser un elemento de la entrada como otro cualquiera (estructurado, pero siguiendo el flujo de la página), no una especie de minitabla flotante. Un saludo, Peter Bowman (discusión) 01:00 6 dic 2015 (UTC)

Ninud: en esta edición liquidaste la categorización de los homófonos y los parónimos en {{pron-graf}}. ¿Había algún motivo concreto detrás de esta decisión? Veo que Categoría:ES:Homófonos y Categoría:ES:Parónimos son relativamente recientes, no contienen muchas entradas y parece que las del español son las únicas que se han creado. Las categorías de variantes comprenden casi veinte idiomas y algunas de ellas están más pobladas: Categoría:Variantes. ¿Cuál es la tendencia: crear cada vez más categorías (paronimia, homonimia, etc.), ir eliminándolas poco a poco, o conservar solo algunas de ellas (variantes)? Un saludo, Peter Bowman (discusión) 00:35 6 dic 2015 (UTC)

tienen muy poca utilidad. lo único que se me ocurre es si se está buscando un ejemplo de un parónimo u homófono y no se puede recordar ninguno. lo mismo ocurre con variantes y grafías alternativas bajo Categoría:ES:Palabras con varias grafías, que lo dejé no sé porque.

este tipo de información no trasciende a los dos (o más) lemas parónimos u homófonos, es decir, no es que analizando el total de la categoría se va a concluir con información estadística útil.

por otro lado no molestan, así que si querés se pueden revivir :/ --Ninud (discusión) 10:45 6 dic 2015 (UTC)

hm, aunque pensándolo de forma más global tal vez sería interesante poder comparar que idiomas tienen más parónimos u homófonos... --Ninud (discusión) 11:11 6 dic 2015 (UTC)

Ninud: ¿y si sustituyéramos estas categorías por anexos (p. ej. Anexo:ES:Homófonos) estructuradas en tablas de dos (o más) columnas: la primera para el lema principal/más usado/cualquier otro criterio, y la otra para su(s) parónimo(s)/homófono(s)/grafía(s) alternativa(s)/variante(s)? Como se suele decir, cada oveja con su pareja, contrastando con el cajón de sastre que son actualmente estas categorías. Mi bot podría ocuparse de revisarlas e irlas completando con el trabajo de los editores, digamos, una vez por semana. Detectaría también enlaces a páginas no creadas, algo que con las categorías no es posible (primero hay que crear la entrada para poder categorizarla). Peter Bowman (discusión) 01:26 7 dic 2015 (UTC)

entendí bien? esos Anexo:XX:Parónimos/Homófonos/etc. serían glosarios de todos los parónimos, homófonos, etc., algo así:

desinfectar: desinfestar, desinsectar

desinfestar: desinfectar, desinsectar

desinflamar: desinformar (sirven de ejemplo, no son parónimos)

desinformar: desinflamar (sirven de ejemplo, no son parónimos)

desinsectar: desinfectar, desinfestar

tema aparte:

volviendo a la idea del buscador avanzado (los filtros del mw:Help:CirrusSearch que mencionaste más arriba creo que no funcionan en español):

podría ser de gran utilidad poder limitar búsquedas combinando palabras que se encuentren en dos, tres o más categorías (ES:Adjetivos; con los prefijos in-/dis-/des-; etc.)

que en el futuro podríamos expandir incluyendo categorías ocultas, etiquetas (tags), (por ejemplo, adjetivos que describen sonidos, gustos, tonos azules, etc.) --Ninud (discusión) 10:31 7 dic 2015 (UTC)

Algo así, aunque creo que preferiría desinfestar: véase desinfectar en lugar de repetir la misma información en varios sitios. La idea original era introducir los datos en una wikitabla con columnas ordenadas alfabéticamente, pero ahora veo que sería mejor usar una simple lista de elementos. Si estas dos últimas categorías todavía presentes en pron-graf (Palabras con varias grafías y Variantes) no son útiles, preferiría quitarlas y ahorrarme ese parámetro adicional (al margen de lo que ocurra con las denominaciones taxonómicas, por lo que comenté anteriormente en este hilo).

En cuanto al buscador, en teoría debería servirte esta herramienta, pero todavía está en construcción: toollabs:catscan2/catscan2.php. Me has recordado que quería probar esto, le echaré un vistazo en otro momento :). Un saludo, Peter Bowman (discusión) 18:16 7 dic 2015 (UTC)

Me parece que voy a renombrar el parámetro propuesto para {{uso}} a nocat=x (cualquier contenido distinto de una cadena vacía). Cuesta predecir qué ocurrirá en el futuro, así que este nombre (no categoría) debería ser más universal (lo que también podría suponer una desventaja, pero por ahora me parece asumible). Mantengo el parámetro tipo=flex para pron-graf, quedando a la espera de alguna posible puntualización en relación con lo indicado en el párrafo anterior, y me gustaría empezar a procesar las entradas a partir de la próxima semana. Peter Bowman (discusión) 02:38 6 dic 2015 (UTC)

Bueno, al final he abandonado la idea de modificar {{pron-graf}} y en vez de eso he suprimido la categorización de variantes y palabras con varias grafías, por resultar de poca utilidad y a la espera de implantar un sistema alternativo (ver mis comentarios y los de Ninud más arriba). He guardado una copia del contenido de las categorías afectadas, que se irán vaciando tras este cambio. De momento tampoco voy a añadir aquel parámetro adicional para la plantilla {{uso}} dado que requeriría revisar y/o modificar toda la familia de plantillas {{contexto}}, algo que preferiría hacer con más tranquilidad en otro momento. Por lo tanto, momentáneamente dejaré las plantillas {{anotación}} con el título Uso y convertiré todas las demás, sirviendo las ideas expuestas en este hilo como posible referencia para el futuro. En un principio, tampoco modificaré la información aportada acerca de los parónimos, pero me guardo como tarea pendiente revisar algun día todas estas formas flexivas y corregir las carencias, sincronizar los datos (p. ej. variantes simétricas), etc. Un saludo, Peter Bowman (discusión) 16:12 12 dic 2015 (UTC)

Tech News: 2015-50

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 calificación de revisiones ayudará a identificar automáticamente ediciones mal intencionadas y ediciones bien intencionadas. La idea es ayudar a bloquear vándalos y a darle la bienvenida a los novatos. Actualmente funciona en Wikidata y en 14 Wikipedias. [23]

Problemas

• La semana pasada no se activó el acceso a la información de Wikidata en Meta. Esto se hará posteriormente. [24]

Cambios esta semana

• Podrás usar wikienlaces en los títulos de los temas de Flow. [25]
• Los usuarios sin registrar (IP) tendrán una barra de herramientas con enlaces a la página de discusión y a las colaboraciones del usuario. Algunas Wikipedias ya tienen esta función. [26]
• Podrás editar el tamaño de los gráficos en el editor visual. Será posible especificar el tamaño en el cuadro de diálogo del gráfico o arrastrarlo para que tenga el tamaño deseado. [27]
• Podrás editar fórmulas matemáticas más fácilmente en el editor visual si no sabes LaTeX. Podrás usar botones en su lugar. [28]
• Podrás usar coloreado de sintaxis en el editor visual cuando escribas formulas matemáticas con LaTeX. [29]
• La apariencia del asistente de subidas cambiará ligeramente. [30]
• La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 8 de diciembre. Se instalará en todas los wikis distintos de Wikipedia y en algunas Wikipedias el 9 de diciembre. Será instalado en las Wikipedias restantes el 10 de diciembre (calendario).
• Las nuevas versiones de MediaWiki estarán disponibles en las Wikipedias en catalán y hebreo los miércoles. Las otras Wikipedias obtendrán la nueva versión de MediaWiki los jueves. [31]

Reuniones

• Puedes participar en la próxima reunión del Equipo del Editor Visual. Durante la reunión podrás decirle a los programadores cuáles son los errores que consideras más importantes. La reunión se realizará el 8 de diciembre a las 19:00 UTC. Consulta cómo participar.
• Puedes participar en la próxima reunión con el Comité de arquitectura. Los temas de esta semana son «Graph/Graphoid/Kartographer: Arquitectura de almacenamiento de datos» y «Constructor de JSON paramétrico». La reunión se realizará el 9 de diciembre a las 22:00 UTC. Consulta como participar.

Cambios futuros

• Una nueva función en pruebas le mostrará a los usuarios enlaces a artículos relacionados al final de cada artículo. No estará activa por defecto. [32]

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.

17:52 7 dic 2015 (UTC)

Enlaces perdidos

Cuando se hicieron cambios automáticos como este en el que las plantillas del tipo XX-ES fueron cambiadas por las de tipo lengua|xx, se perdieron muchos enlaces a vocabulario relevante. Esos enlaces deberían ser movidos a las plantillas pron-graf con el prefijo alt= como, por ejemplo, se muestra aquí. La cantidad de enlaces afectados es probablemente del orden de miles, de modo que convendría que un bot se encargara de ellos. Eso, o crear/implementar/activar una función alt= para las plantillas lengua|xx. Saludos. --95.20.46.120 15:48 8 dic 2015 (UTC)

Hola. Sí, indiqué al bot que los llevara a un parámetro inexistente de {{lengua}} para evitar perder esa información. Nótese que no hay forma de implementar esta función en la nueva plantilla del modo en que funcionaba antiguamente con las {{XX-ES}}. El cómputo a fecha del 1 de diciembre es de 4679 páginas afectadas. Cuando no era posible usar dicha plantilla, el bot trasladó los enlaces a un comentario de la forma <!-- NO EDITAR: alt=... -->; solo se han dado estos dos casos: horizon, 今日. Decidí adoptar esta solución provisional porque no tenía claro si debía seguir lo acordado en Wikcionario discusión:Estructura o usar la nueva {{pron-graf}}. La primera opción habría consistido en escribir algo como Véanse [[a]], [[b]] y [[c]]. en la sección de etimología, siendo a, b y c las palabras que conforman la locución (también podría usarse {{etimología2}}, más ejemplos: sustantivo común en cuanto al género, Usuario:Ninud/estructura4). Pasar a {{pron-graf}} llevaría a preguntarse si tiene sentido incluir una sección etimológica en las locuciones (y no solo, ver a se mira), véase esta conversación: Especial:Diff/3034320, Especial:Diff/3034361.

Las preguntas que se me plantean son dos:

• ¿Llevamos todos estos enlaces, situados provisionalmente por el bot en la plantilla {{lengua}}, al parámetro alt de {{pron-graf}}?
• Si se acuerda la solución propuesta en el punto anterior, ¿qué hacer con la etimología en las locuciones (y similares, el caso de estudio son principalmente entradas formadas por más de una palabra)? ¿Debería borrarla con el bot si está vacía, y permitir que sea facultativa, es decir, que pueda ser añadida por los editores si consideran que hay algo que valga la pena mencionar en esta sección?

Un saludo, Peter Bowman (discusión) 20:47 8 dic 2015 (UTC)

+ WN:Café/2015 10#¿Enlaces dentro del lema?. Peter Bowman (discusión) 14:57 15 dic 2015 (UTC)

Y otra pregunta: ¿estos enlaces deben apuntar siempre al lema base de cada palabra, o se admiten formas flexivas (ver halcones campestres)? Peter Bowman (discusión) 23:14 13 dic 2015 (UTC)

diría a los lemas base, aunque no es tan importante ya que no habría cambios visuales (alt=[[alcón|alcones]] [[campestre]]s) --Ninud (discusión) 09:48 14 dic 2015 (UTC)

A este respecto no habría cambios, pero en el caso citado se da la casualidad de que aún no existe la entrada halcones. Si aceptáramos los enlaces en el parámetro alt de pron-graf como un sustituto de la "etimología" (aunque realmente no sea tal), aparte de evitar enlaces a formas inexistentes, redirigir al lector al lema base le ahorrará otro clic (las propias formas flexivas son redirecciones suaves). Un saludo, Peter Bowman (discusión) 10:57 14 dic 2015 (UTC)

Volviendo a este tema, no parece que los cambios propuestos sean controversivos, y además ya gozan de cierta aceptación, tanto en el primer punto (llevar los enlaces a alt, siguiendo el comentario inicial del autor del hilo) como en el segundo (en nuestra conversación, Romanophile dudó de la necesidad de incluir el apartado Etimología). En el grupo de las secciones de carácter reducido, es decir, que carecen de ciertos elementos incluidos por defecto (como la etimología), y al que se unirían ahora las locuciones, están ya las grafías/variantes alternativas/obsoletas, las contracciones, las formas flexivas, las formas reconstruidas del protopolinesio e indoeuropeo y los translingüísticos. Trataré de aplicar estos cambios durante la próxima semana. Un saludo, Peter Bowman (discusión) 23:13 24 dic 2015 (UTC)

sobre la necesidad de las etimologías de locuciones (en su momento también tuve mis dudas al respecto): además de mencionar la suma de palabras se puede ofrecer información como a partir de cuándo y dónde se comienza a usar (primer testimonio y el ámbito de este). y felices fiestas para todos! :) --Ninud (discusión) 09:09 25 dic 2015 (UTC)

Un proyecto IEG rechazado

Hola colegas hispanohablantes,

Estoy con pena decirle que mi proyecto de Wikiproyecto Siriono ha sido rechazado. Era un proyecto de un lingüista para integrar su base de datos sobre una lengua boliviana en peligro de extinción a partir del programa FLEx. Despues, era planeado de viajar a Bolivia para capacitar a los hablantes a leer y contribuir al Wikcionario. No era para que sean impresionante contribuidores pero de mostrar que el Wikcionario puede ser un útil increíble por las lenguas en peligro de desaparecer, no solamente como archivo pero como lugar de colaboración para que la lengua y su diccionario quedan como propriedad comuna. La decisión cayo en inglés así:

Without a better understanding of how data transfer from FLEx to Wiktionary would work, and in light of the fact that current Wiktionary capabilities are perhaps too narrow to broadly accommodate the needs of linguistic researchers, we are concerned that this project would not scale. When weighing the high cost of funding the project team’s travel to Bolivia against concerns about the potential for long-term impact, we felt that this project was not ultimately a good fit with Wikimedia’s scope at this time. You might consider the possibility of resubmitting your proposal in the future as a more narrowly focused pilot investigating the feasibility of data transfer between Wiktionary and FLEx, and establishing best practices for accommodating linguistic research on Wiktionary.

Eso me puso de pensar en muchas cosas que escribí allá en inglés también. Aquí vengo para comentarle especialmente de una parte de la decisión que considera que los Wikcionarios no son puestos para aceptar lingüistas. Creo que eso es la consecuencia de una falta de comunicación externa por parte de los Wikcionarios. Se ve que los objetivos y sucesos de los Wikcionarios no son muy visible afuera de los proyectos. Podemos ser muy contento de la evolución del proyecto en esos últimos diez años pero no se sabe afuera del proyecto! Nos hemos dado cuenta de eso en el Wikcionario en francés hace poco y hemos intentado de hacer un poco de comunicación. Entonces, estoy muy interesado para saber ¿que se pasa en el Wikcionario en castellano? Para darle una idea de lo que hacemos en la versión francesa, hemos hecho charlas publicas por ejemplo a una conferencia de lexicógrafos y por un encuentro sobre los proyectos libre (en vídeo), hemos participados en editathon (ej. en noviembre sobre el Arte en la Renacimiento), hemos empezado un tipo de noticiero mensual como SignPost por y tenemos un encuentro publico cada mes en la ciudad de Lyon, en Francia. ¿Hay algo parecido en el Wikcionario en castellano? Por favor, avisame, que le pongamos en nuestra pagina de noticias Actualités y que mostramos al mundo el poder del Wikcionario Noé (discusión) 15:49 8 dic 2015 (UTC)

Puede que sea cierto, pero es porque ellos tampoco lo impulsan haciendo mas fácil la edición y la utilización del mismo, por ejemplo usando wikidata (cosa que si tienen casi todos los otros proyectos hermanos, por mas chicos que sean), aplicaciones para consultar las definiciones, etc. --Esceptic0 (discusión) 11:40 10 dic 2015 (UTC)

Estoy plenamente desacuerdo que no hubo mucha evolución técnica por los Wikcionarios. Hablando de Wikidata, ya empezó un voto para impulsar un cambio, dentro de los deseos generales por 2016. Pueden ir a votar. Noé (discusión) 13:13 10 dic 2015 (UTC)

lenguas de origen: origen según el trayecto

sigue el hilo de 2015 04/Lenguas de origen (escalonamiento)

• a falta de propuestas y la falta de utilidad del sistema actual, creé {{origen}}, que permite especificar desde que lengua y a partir de cuando un lema se introdujo dentro del continuo de otra lengua.

para mantenerlo breve, ideal hubiera sido con el símbolo < "deriva de(l)" (por ej. en el continuo del alemán: Categoría:DE:<GMH<GOH<GEM<INE), pero aparentemente no está admitido. provisionalmente suplanté < por "del"

el resultado se puede ver en rund (Categoría:DE:Del GMH, del FRO), y no se ve bien así... Categoría:DE:GMH:FRO podría ser confuso...

¿Y qué tal con algo como Categoría:DE ← GMH ← FRO? Sin los dos puntos. Peter Bowman (discusión) 16:32 10 dic 2015 (UTC)

--Ninud (discusión) 13:10 10 dic 2015 (UTC)

Tal vez sea mejor usar siempre minúsculas, del mismo modo en que ya lo hacemos en las plantillas de sección/encabezamiento ({{origen|de|gmh|fro}}), aunque esto no es importante. Sigue sin convencerme la idea de las categorías... Es inevitable que la cantidad de combinaciones llegue a ser muy elevada (multipliquemos tan solo las que propones para el alemán, junto con las incógnitas indicadas por paréntesis y signos de interrogación, por el número de idiomas en Wikcionario), siendo muy difíciles de mantener y, además, que muchas de ellas contengan solo unas pocas entradas. Estoy experimentando con aplicaciones web en los servidores de Wikimedia y se me ocurre la idea de crear una herramienta similar al gadget que funciona en las subcategorías de Categoría:Palabras por origen y lengua, esta vez abriendo la posibilidad de generar árboles de étimos según la lengua de procedencia y con más control sobre cómo mostrar esa información. Sería una especie de base de datos actualizada periódicamente a partir de las plantillas {{origen}} incluidas en las entradas (cumplirían el papel de etiquetas o algo similar). No me opongo a la idea de usar esta plantilla, tan solo quería comentar esta alternativa, que no llegaría pronto por falta de tiempo de mi parte para programar algo así, y por la necesidad de implantar la plantilla en un número suficiente de entradas para que tenga sentido generar estos árboles de datos. Un saludo, Peter Bowman (discusión) 16:32 10 dic 2015 (UTC)

perdón, ayer me tenía que ir y dejé todo sin más explicaciones que el hilo a la discusión de mayo.

el problema con las etimologías en wikcionario comienza en la plantilla {{etimología}}, que admite muchas posibilidades sí, de hecho sirve para la gran mayoría de las lenguas, pero para un puñado de lenguas ya no alcanza.

Categoría:DE ← GMH ← FRO: sin ":" buena idea; las flechitas generalmente señalan "véase" pero se entiende; incluir {{uc:{{{2,3,...}}}}} para automatizar mayúsculas, otra buena idea :)

la cantidad de categorías es un tema que parece preocupar y que parece que no expliqué lo suficientemente bien en mayo.

genera pocas categorías más de las que hay! cuando en teoría se podría crear un sinfín de combinaciones en la práctica son pocas las combinaciones posibles.

Tomemos el alemán como ejemplo:

1. DE ← GMH ← GOH ← GEM ← INE: para lemas que estuvieron en el continuo desde el protoindoeuropeo (schön, schlecht, etc.)
2. DE ← GMH ← GOH ← GEM ← ??: para lemas que entran a partir del protogermánico de origen incierto (para la mayoría de estos lemas, que son muchos, se supone un mismo sustrato no indoeuropeo, dick, nass, Bild, etc.). A diferenciar de Categoría:DE:Palabras de origen incierto, como Sparte!
3. DE ← GMH ← GOH ← GEM ← LA: para los que entraron del latín antes de la segunda mutación consonántica, antes del siglo VIII (kurz, Tisch, etc.)
4. DE ← GMH ← GOH ← LA: los que no sufrieron dicha mutación, es decir, entraron después del siglo VIII (Pein, etc.)
5. DE ← GMH ← LA: del latín entre el 1050 y el 1350 (ozeanisch, etc.)
6. DE ← GMH ← FRO: para los que vienen del francés antiguo (rund, simpel, etc.)

y eso es todo

las que entrarían dentro del grupo DE ← GMH, aquellas que se formaron durante aquel periodo (Adler, etc.) quedan en el grupo Categoría:DE:Palabras de origen alemán medio.

el resto entran todas después del 1350, es decir Categoría:DE:Palabras de origen de lo que fuere.

a aquellas categorías hay que restarle 3: Categoría:DE:Palabras de origen alemán antiguo, Categoría:DE:Palabras de origen protogermánico, Categoría:DE:Palabras de origen protoindoeuropeo

son apenas tres categorías más --Ninud (discusión) 12:56 11 dic 2015 (UTC)

Perdón, creo que ya lo voy entendiendo. Pensaba que esa cadena de étimos debía ser aplicable en todos los casos, p. ej. una palabra alemana contemporánea que derive del inglés y de allí seguir la cadena hasta el final, y así con todas las combinaciones de Categoría:DE:Palabras por origen. En cambio, estás proponiendo restringir esas cadenas a una lengua de procedencia en concreto, ¿verdad? (aquí sería el GMH). Bueno, no me opongo. Eso sí, ojalá fuera posible implementar un sistema de datos estructurados en las secciones etimológicas de modo que solo hiciera falta introducir el primer étimo (en rund sería el alemán medio runt) y, por medio de algún gadget, pulsar un botón para mostrar la cadena que sigue a partir de ahí. Y si toda esta información estuviera en una base de datos, se evitarían incongruencias y fallos de sincronización (supongamos que en runt no indicamos que procede del francés antiguo reont, sino de otra palabra diferente). Básicamente, la idea que comenté más arriba sería posible de implementar, y más completa todavía, si tuviéramos acceso a Wikidata :). En tal caso ni siquiera haría falta introducir estas categorías. Un saludo, Peter Bowman (discusión) 19:40 11 dic 2015 (UTC)

como propuesta alteré la sección de etimología en schön.

- evité usar las plantillas {{etimología}} o {{etim}} (más que nada para evitar la categorización, pero para que tampoco inicie con "Del/del", así la comparación no es tan afirmativa)

- para mejor visibilidad separé los pasos tras numeradores.

- y evité detallar la derivación exacta entre el protoindoeuropeo y el protogermánico, que en el caso de schön es bastante extensa, y será mejor ponerla dentro de la entrada del protogermánico *skauni- (aunque bajo el argumento de que dicha entrada no será creada en próximo futuro, se podría agregar a la etimología de schön).

--Ninud (discusión) 11:24 12 dic 2015 (UTC)

PD: el gadget que proponés suena interesante, pero nos falta la base de datos :( --Ninud (discusión) 11:27 12 dic 2015 (UTC)

Me gusta la idea de Ninud en schön y también la de la base de datos de Peter Bowman. Chicos, en otra sección se habla del Wikidata que ya viene. ¿Estarán considerando cosas como esta? Podría ser una revolución para los wikcionarios y es posible que el proyecto lograra hacer cosas iguales o mejores que las de WiktionaryZ OmegaWiki y que tengamos que jubilarnos. cc. Usuario:Esceptic0. Saludos. Lin linao ¿dime? 20:25 12 dic 2015 (UTC)

Sí, aunque será un proceso escalonado. De lo que no se habla en la votación en Meta mencionada en aquel hilo es que hay una "fase 0" pensada para los wikcionarios; esta consistiría en quitarse de un plumazo todos los interwikis del espacio de nombres principal y llevarlos a Wikidata (la particularidad de los wikcionarios radica en que una entrada de enwikt se llamará casi siempre igual que una de jawikt, por poner un ejemplo, luego conectar dos artículos en proyectos diferentes es algo trivial; compárese esto con las wikipedias donde dicha tarea se realiza manualmente dada la incapacidad de los bots para traducir un término enciclopédico). La primera fase a la que creo que se refiere JAn Dudík es el soporte para los enlaces en otros espacios de nombres, p. ej. las categorías, donde está haciendo un gran trabajo de sincronización con su bot: [33]. Finalmente, en una fase posterior, las entradas, ya subidas a Wikidata, permitirían especificar propiedades, como la etimología de nuestro ejemplo. Aquí se puede consultar el borrador de la última propuesta: d:Wikidata:Wiktionary/Development/Proposals/2015-05.

Yo no anunciaría nuestra jubilación tan rápidamente :). Cierto es que el grueso de la información podría pasar a otro proyecto, pero primero hay que construir herramientas para poder usarla (plantillas, accesorios, módulos...). Harán falta años para eso. En el fondo solo seremos un servicio que utilice Wikidata, mientras que OmegaWiki parece estar orientado desde sus inicios a la presentación de datos estructurados. Un saludo, Peter Bowman (discusión) 21:14 12 dic 2015 (UTC)

volviendo al tema, para el español tendríamos en teoría el continuo ES ← OSP ← LA ← ITA ← INE.
pero con el material que tenemos sobre el latín, los pasos previos a este no son necesarios, luego quedaría:

• ES ← OSP ← LA
• ES ← OSP ← EU (euskera)
• ES ← OSP ← XAA/AR (árabe hispánico/árabe)
• ES ← OSP ← XVN/GEM (vándalo/germánico)
• ES ← OSP ← ?? (subgrupos: XIB?, probable o posiblemente del ibérico; XCE?, probable o posiblemente del celtibérico; etc.)
• etc.

aquí chocamos con la problemática en torno al español medieval (OSP) cuyo léxico aún no se completó (Diccionario del Español Medieval de Bodo Müller, que se publica en forma de revista en dos tomos anuales creo — tema aparte: alguien me puede explicar, cómo es qué un alemán se está encargando de esta labor?), además existe el Diccionario de castellano antiguo de Manuel Gutiérrez Tuñón, pero con apenas 300 páginas no debe ser una obra muy completa tampoco.
y luego los préstamos de otras lenguas a partir del español moderno. es decir, diferenciar entre

• Categoría:ES ← OSP ← LA (continuo) y Categoría:ES ← LA (préstamo después del siglo XV)
• Categoría:ES ← OSP ← EU (préstamo antiguo) y Categoría:ES ← EU (préstamo después del siglo XV)
• Categoría:ES ← OSP ← AR (préstamo antiguo) y Categoría:ES ← AR (préstamo después del siglo XV)
• etc.

--Ninud (discusión) 13:29 13 dic 2015 (UTC)

aunque en el caso del español probablemente va a ser mejor trabajar con subcategorías:

Categoría principal: Categoría:ES:Palabras de origen latino

subcategorías: Categoría:ES ← OSP ← LA ("lemas antiguos") y Categoría:ES ← LA (cultismos latinos/latinismos)

algunos ejemplos:

Categoría:ES ← OSP ← LA:

• lejos [ˈle.xos], español antiguo lexos [ˈle.ʃos], latín laxius /ˈlak.si.us/ "más separadamente" (comparativo adverbial de laxus /ˈlak.sus/ "amplio").
• dejar [deˈxaɾ], español antiguo dexar [deˈʃar] y lexar [leˈʃar], latín laxō, -āre /ˈlak.soː, lakˈsaː.re/ "aflojar" (de laxus).

Categoría:ES ← LA o Categoría:ES:Cultismos latinos:

• laxo [ˈlak.so], latín laxus.
• laxar [lakˈsaɾ], latín laxō, -āre.

--Ninud (discusión) 11:19 14 dic 2015 (UTC)

sobre el formato de las etimologías españolas:

sin alterar el formato actual se podría hacer como en lejos, aprovechando la plantilla {{etim}} para categorizar el lema dentro de ES:Palabras de origen latino.

o hacer algo similar a lo que propongo para los lemas alemanes:

• Español antiguo lexos (desde c 1196). esta parte es complicada por no contar con un diccionario, pero con algo de investigación se puede incluir usando el CORDE
• Latín laxius ("más ampliamente, más separadamente"), adverbio comparativo de laxus ("amplio").
• Protoindoeuropeo [[*sleg-#|*sleg-]] ("aflojarse, relajarse"). sin categorizar y evitando las extensas derivaciones entre el latín, el protoitálico y el protoindoeuropeo se puede incluir la raíz protoindoeuropea

--Ninud (discusión) 13:07 14 dic 2015 (UTC)

Apartado Historia en las entradas

Volviendo al hilo WN:Café/2015 03#voto para reunir "Historia" a Etimología, he preparado esta lista de páginas donde figura un elemento Historia, como ayuda para quien quiera adaptarlo para Etimología o simplemente revisar su contenido: Usuario:PBbot/historia. Veo que hay un montón de información propia de una enciclopedia que posiblemente sea preferible eliminar, y hay también casos que podrían tener mejor cabida en otros apartados de las entradas. Un saludo, Peter Bowman (discusión) 18:37 10 dic 2015 (UTC)

¿Qué campañas de IdeaLab te gustaría ver?

¡Hola! Quisiera tu ayuda para escoger los temas para las nuevas campañas que se podría realizar el año entrante en IdeaLab. Las campañas están diseñadas para atraer propuestas de los colaboradores de los proyectos Wikimedia orientadas a resolver necesidades o problemas en los proyectos de Wikimedia. Para participar puedes:

• Familiarizarte con esta consulta y revisar los temas propuestos por otros colaboradores.
• Votar por los temas para las nuevas campañas o proponer uno nuevo en la encuesta AllOurIdeas (en inglés).
• Discutir los temas para las campañas y formular sus preguntas en la página de discusión de IdeaLab, o sentirte libre de discutir y proponer ideas para campañas en esa página de discusión.

Muchas gracias,

I JethroBT (WMF), Community Resources, Wikimedia Foundation. 00:11 12 dic 2015 (UTC)

Tech News: 2015-51

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 de esta semana

• Meta podrá usar información de Wikidata. [34]
• La nueva versión de MediaWiki se instalará en los wikis de prueba y en MediaWiki.org el 15 de diciembre. Se instalará en todos las wikis ajenos a Wikipedia y en algunas Wikipedias el 16 de diciembre. Se instalará en las Wikipedias restantes el 17 de diciembre. (Calendario).

Reuniones

• Puedes participar en la próxima reunión con el Equipo del Editor Visual. Durante la reunión podrás decirle a los desarrolladores cuáles son los errores que consideras más importantes. La reunión se realizará el 15 de diciembre a las 19:00 UTC. Consulta cómo participar.
• Puedes participar en la próxima reunión con el Comité de Arquitectura. El tema de esta semana es discutir la agenda para el Encuentro de Desarrolladores de Wikimedia. La reunión se realizará el 16 de diciembre a las 22:00 UTC. Consulta cómo participar. [35]

Cambios futuros

• El año entrante se implementará un nuevo administrador de accesorios. El nuevo sistema de accesorios se llama Gadgets 2.0. [36]

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

17:41 14 dic 2015 (UTC)

lemas que no se recogieron en ningún diccionario

cimbrel, chavismo, etc.
en lugar de poner más de un {{ejemplo}} podríamos crear subpáginas donde se pueden colectar referencias (citas de libros, diarios o revistas).
para cimbrel señalar bajo ejemplos y luego registrar referencias bajo cimbrel/ES/Referencias.
--Ninud (discusión) 12:48 16 dic 2015 (UTC)

Lo ideal creo que sería registrar esas citas en Wikiquote, ya que esa es su función, y añadir los enlaces correspondientes en las entradas (en un apartado al mismo nivel que los ejemplos, como hacemos ya con los tesauros, o en Véase también). Un saludo, Peter Bowman (discusión) 13:10 16 dic 2015 (UTC)

Hola. No entiendo. Todas las entradas requieren de referencias y ejemplos, ¿qué tienen de especial las que no salen en los diccionarios? Pienso en especial en el castellano y su todavía pobre recolección de información dialectal o al día y en idiomas con poca tradición de escritura, como el mapudungun o casi ninguna, como el kawésqar. Por otra parte, hay un problema con los ejemplos y la licencia: el Wikcionario tiene una licencia libre, mientras que los ejemplos no la tienen, si los incluimos es gracias a que existe derecho de cita, pero en ninguna parte se explica que no son material libre como el resto de las entradas. Saludos. Lin linao ¿dime? 19:28 16 dic 2015 (UTC)

Peter Bowman: la función de Wikiquote es la recolección de frases célebres. lo que propongo es un "mini corpus" de referencias de cierto lema en una subpágina que luego se pueda enlazar bajo ejemplos (sí, como los tesauros :))

"mini corpus" porque por temas legales no podemos incluir la mayoría de las obras completas (modernas) en Wikisource, pero sí citas (más allá de no presentar problemas legales, los autores de las obras citadas se van a ver beneficiados por la propaganda gratis que le hacemos)

para el latín este es otro tema (ya mencionado hace un tiempo) que tarde o temprano contaremos con el corpus completo en Wikisource latina y en algún momento se podrá incorporar una herramienta para aprovecharlo mejor.

Lin linao: a diferencia de la RAE nosotros no tenemos límites cuantitativos del uso de los lemas. es decir, si un lema aparece 2-3 veces en la literatura lo podemos recoger citándolo (si la definición es clara). acerca de las lenguas con poca o sin tradición escrita y sin diccionarios lastimosamente no podemos hacer nada en wikcionario ;(

en Usuario:Ninud/Propuestas/Cimbrel/ES/Referencias un bosquejo de como se podría ver una subpágina de referencias para el lema cimbrel (pido disculpas por usar un lema malsonante ;P)

--Ninud (discusión) 13:03 17 dic 2015 (UTC)

De acuerdo, con la mención del minicorpus ya me ha quedado más claro :) (aunque, ciertamente, no solo hay frases célebres en Wikiquote: también he visto extractos literarios, principalmente de poesía, diálogos de entrevistas, artículos periodísticos, etc.). Fijándonos un poco en enwikt, las referencias podrían estar en un espacio de nombres dedicado, por ejemplo, Referencias: o Citas:, y este ser accesible desde una pestaña superior, al lado de Entrada y Discusión. Véase en:world y en:Citations:world. A elegir entre la opción de reunir todas las citas en una misma página, o crear una subpágina para cada idioma, como en tu propuesta. Una nueva plantilla indicaría un enlace directo a esta página de citas (similar a como se enlazan los tesauros) para el idioma correspondiente, tal vez con una condición ifexist que, en caso de no detectar dicha página, mostraría un texto incitador para añadir nuevas referencias (no sé si es buena idea). Y a todo esto podría añadirse un gadget que, tras pulsar un botón al lado del texto insertado por esta plantilla, permitiría mostrar/ocultar todas las referencias en forma de lista en la misma entrada, sin necesidad de abandonar la página. Un saludo, Peter Bowman (discusión) 17:14 17 dic 2015 (UTC)

Disculpa, sigo sin entender por qué propones esto para cimbrel y no para gato. Y también por qué es mejor que gato y cimbrel tengan sus referencias y ejemplos de uso dentro de la misma página de la entrada. Saludos. Lin linao ¿dime? 18:19 17 dic 2015 (UTC)

Imagino que la duda va dirigida a Ninud, yo solo propongo una forma de implementar esto en caso de ser aprobado. De todos modos, no veo que nadie mencione la palabra gato, no entiendo esa comparación. Un saludo, Peter Bowman (discusión) 18:42 17 dic 2015 (UTC)

Sí, el mensaje es para Usuario:Ninud. Saqué a colación al gato porque no entiendo la diferencia entre palabras "que no se recogieron en ningún diccionario" como cimbrel y otras que sí, como gato o mesa y por qué habría que darle algún tratamiento especial a las primeras. Saludos. Lin linao ¿dime? 20:19 17 dic 2015 (UTC)

perdón, inicié la propuesta dando poca información (que a veces uno anda corto de tiempo ;P)

la idea surge de la necesidad y obligación(!) de referenciar lemas y acepciones, que no es nada nuevo: si cimbrel no figuraba en algún documento que podamos aceptar como fuente, íbamos a tener que borrar la entrada.

Peter Bowman: sí, había visto la propuesta del wikcionario inglés, por eso, para evitar sobrecargar la página, la idea de crear subpáginas, donde podemos enumerar todas las citas que estén al alcance (que dependiendo del lema puede ser muy extensa). al inicio de la entrada se podría señalar que hasta la fecha el lema no figura en el CORPES y al final de la lista se podría agregar un enlace a buscadores, por ejemplo al buscador dentro de google.books [https://www.google.com/search?tbm=bks&q=LOQUEFUERE]

interesante la idea de crear una pestaña a la altura de Entrada y Discusión, pero tener en cuenta que la propuesta es de separarlas por idiomas, nuevamente con el argumento de lo extensivo que pueden llegar a ser estas listas, que a medida que pasa el tiempo irían creciendo, emulando la función de un corpus (por ejemplo, solamente dentro de El País chavismo figura 1265 veces). y para responderle a Lin linao, claro que se puede hacer lo mismo con los lemas que ya fueron recogidos en otros diccionarios. pero sería un esfuerzo bastante adrede que para esos casos contamos con los recursos que nos pone a disposición la RAE y alcanza con poner un ejemplo.

supongamos que se me ocurra introducir al wikcionario algunos lemas que no se extiendan más allá del ámbito de misiones, provincia en el litoral argentino entre brasil y paraguay (y donde casualmente vivo ;P), que incluye varios préstamos del guaraní, como guaú, yaguá, etc., y del portugués (brasilero), como miñoca, etc., o también neologismos, como reviro, etc.

antes de crear estas entradas el primer paso como editor debería ser investigar si los lemas existen en textos oficiales. si no encuentro referencias válidas y opto por publicar la entrada sin referencias, estaría perdiendo mi tiempo, que la entrada sería borrada más tarde.

miñoca es un buen ejemplo de un lema bien entablado en el léxico misionero (lombriz se desconoce o se conoce como lenguaje culto) y me resultó muy fácil encontrar muchos ejemplos en artículos de diarios locales.

me sorprende haber encontrado buenos ejemplos con guaú y yaguá que los contaba dentro del lenguaje familiar.

Creo que las referencias tienen que darse en una cantidad que asegure que lo escrito se sustenta. Es decir, me parece innecesario consignar todos los ocasiones en que aparece un término. Y eso vale lo mismo para gato que para cimbrel. Si nos ponemos de acuerdo en que las citas vayan en subpágina, como creo que hacen en de:wikt, me parece bien, pero sin hacer diferencias (entre otras cosas, porque la neutralidad también consiste en no darle un crédito especial a diccionarios como si no aparecer en ellos fuera indicador de alguna propiedad de la palabra, cuando suele ser indicador de la (poca) diligencia de los lexicógrafos o de las limitaciones del papel). Saludos. Lin linao ¿dime? 18:03 18 dic 2015 (UTC)

el wikcionario alemán archiva las flexiones de adjetivos y verbos en páginas separadas (aunque no subpáginas, ver de:Flexion:rot "rojo", de:Flexion:schlafen "dormir"), todo lo demás lo apilan en la misma entrada, ver el apartado Beispiele "ejemplos" en Haus "casa".
en lo demás estoy totalmente de acuerdo con lo que decís. mi propuesta no es la de exigir todas las referencias que existan si no de crear un espacio donde se las pueda listar sin afectar la entrada principal.
los lemas miñoca y guaú acompañé con una cita a cada uno, que podrían haber sido dos. hasta acá no hay nada nuevo, es lo que exigimos en wikcionario. pero si un editor desea poner más, muchas o todas las citas que encuentre lo deberá hacer en la subpágina. es decir, no es necesario, pero sí bienvenido, ¡y que no sea en la entrada principal!
sobre los lexicógrafos y los límites de los diccionarios de papel: el problema no es la diligencia de los lexicógrafos si no que su escuela y mentalidad exclusiva. la digitalización del léxico en teoría rompió con el argumento de exclusión de lemas, hasta el momento marginados de los diccionarios de papel para ahorrar espacio (que si incluimos tal lema tenemos que incluir todos aquellos también, etc.). este problema no existe en un diccionario digital (que si un lema es poco usado, la entrada de dicho lema simplemente será poco visitada, pero sobre todo no estorba). esperarse que la mentalidad de los lexicógrafos cambié de exclusiva a inclusiva de un día para el otro no es realista (paciencia, me imagino que están transicionando ;P)
--Ninud (discusión) 11:38 19 dic 2015 (UTC)

leyendo la etimología de mensú que propone la RAE (ver mensú) tengo que admitir que algo de pereza tienen. que técnicamente, decir que se trata de un acortamiento, no es incorrecto, pero sí una etimología muy incompleta. cuando menos podrían haber mencionado que se trata de un guaranismo... aunque supongo que deberíamos estar agradecidos, que incluyeron el lema :/ --Ninud (discusión) 13:05 20 dic 2015 (UTC)

Pienso que poner más citas de las necesarias para referenciar es inadecuado porque este es un diccionario, no un almacén de referencias y ejemplos de uso. Si se necesitan 1 o 10 citas, bien, pero es difícil que en cada entrada haga falta un archivo de citas. Saludos. Lin linao ¿dime? 01:15 21 dic 2015 (UTC)

un diccionario, si apunta a ser creíble y legítimo, o se basa en un corpus, que lógicamente y por definición es lo más extenso posible, o se basa en otros diccionarios que a su vez están basados en un corpus.

ahí la diferencia entre gato y cimbrel en wikcionario. teniendo acceso al corpus de la RAE hace innecesario repetir las referencias para lemas como gato.

en cambio cimbrel, miñoca, guaú, y todos aquellos lemas que todavía no (y tal vez nunca) figuren en el corpus de la RAE, y requieren de citas, ganarían seriedad si se los respalda con un número mayor de referencias.

y repito: no exigimos todas las citas posibles, ni lo vamos a hacer en el futuro. es suficiente con una o dos. pero si hablamos de lo adecuado, entonces sí, para muchos lemas lo más adecuado sería de agregar todas las citas posibles, donde el interesado pueda comparar los distintos ejemplos, sus matices o lo que sea (y no preocuparse que nadie se va a tomar el tiempo de listar todos los ejemplos de chavismo, kirchnerismo, etc., y la cantidad de ejemplos donde figuran los lemas de verdadero interés es muy limitada)

lo que propongo es simplemente un espacio separado de la entrada principal para no sobrecargarla, adelantándonos a lo que sucederá en el futuro (ver wikcionario inglés).

--Ninud (discusión) 15:22 21 dic 2015 (UTC)

Propuesta para nuevo accesorio: Reference Tooltips

Quería preguntar si habría interés por instalar aquí el gadget mw:Reference Tooltips. Su funcionamiento, tal como se puede apreciar en la primera imagen, consiste en generar un cuadro emergente o popup al pasar con el cursor por encima de una nota al pie, de modo que no haría falta desplazar la página hasta el final para consultar la referencia. Hay planes para añadir esta posibilidad a la función en pruebas "Cuadros emergentes", pero llevan estancados ya varios meses (y aún habría que esperar a que activen la función por defecto para todos los lectores). Un saludo, Peter Bowman (discusión) 17:32 17 dic 2015 (UTC)

es una cuestión de forma, si no afecta técnicamente con algo negativo no veo porqué oponerse--Esceptic0 (discusión) 21:01 17 dic 2015 (UTC)

No debería, hace tiempo que lo uso y no he advertido ningún error, incluso creía que ya estaba instalado (lo tengo activado globalmente). Subrayo esto porque antes no lo mencioné explícitamente: el fin es que sea una ayuda para los lectores, luego la propuesta es activarlo para todos por defecto (anónimos inclusive). Un saludo, Peter Bowman (discusión) 00:36 18 dic 2015 (UTC)

bienvenido sea :) --Ninud (discusión) 13:59 18 dic 2015 (UTC)

Esceptic0, Ninud: ya está disponible en las preferencias bajo la descripción "Reference Tooltips: permite consultar el contenido de cualquier referencia al pasar el cursor sobre ella, sin la necesidad de desplazarse hasta el pie de página.". No me di cuenta de que también estaba en eswiki, de donde finalmente será cargado el código del gadget, ya traducido al español. Veamos qué tal, y si no hay quejas, lo activaré para todos :). Un saludo, Peter Bowman (discusión) 17:45 22 dic 2015 (UTC)

ya lo activé, funciona perfectamente. gracias! --Ninud (discusión) 11:34 23 dic 2015 (UTC)

Hecho. Un saludo, Peter Bowman (discusión) 16:02 26 dic 2015 (UTC)

Get involved in Wikipedia 15!

This is a message from the Wikimedia Foundation. Translations are available.

As many of you know, January 15 is Wikipedia’s 15th Birthday!

People around the world are getting involved in the celebration and have started adding their events on Meta Page. While we are celebrating Wikipedia's birthday, we hope that all projects and affiliates will be able to utilize this celebration to raise awareness of our community's efforts.

Haven’t started planning? Don’t worry, there’s lots of ways to get involved. Here are some ideas:

• Join/host an event. We already have more than 80, and hope to have many more.
• Talk to local press. In the past 15 years, Wikipedia has accomplished extraordinary things. We’ve made a handy summary of milestones and encourage you to add your own. More resources, including a press release template and resources on working with the media, are also available.
• Design a Wikipedia 15 logo. In place of a single icon for Wikipedia 15, we’re making dozens. Add your own with something fun and representative of your community. Just use the visual guide so they share a common sensibility.
• Share a message on social media. Tell the world what Wikipedia means to you, and add #wikipedia15 to the post. We might re-tweet or share your message!

Everything is linked on the Wikipedia 15 Meta page. You’ll find a set of ten data visualization works that you can show at your events, and a list of all the Wikipedia 15 logos that community members have already designed.

If you have any questions, please contact Zachary McCune or Joe Sutherland.

Thanks and Happy nearly Wikipedia 15!
-The Wikimedia Foundation Communications team

Posted by the MediaWiki message delivery, 20:58 18 dic 2015 (UTC) • Por favor, ayuda a traducir a tu idioma • Ayuda

citar libros en Wikisource

retomando el conocido código [[s:entrada en wikisource]] agregué a {{cita libro}} los parámetros |s=<título en wikisource>|, |scap=<capítulo en wikisource>| y |scapalt=<capítulo en subpágina del título>| para poder citar libros en wikisource (solo en español).
se pueden ver aplicados en mensú y bostero.
aunque pensándolo mejor creo que va a ser mejor crear una plantilla aparte y mejor adaptada.
--Ninud (discusión) 13:27 20 dic 2015 (UTC)

Super. Quizás se podría citar también en otros idiomas con un párámetro adicional |lengs=. Como todas las wikisource, menos la "cajón de sastre" tienen la dirección <abc>.wikisourge.org, donde <abc> es el código ISO o SIL del idioma, creo que para algún entendido en plantillas no será difícil de redactar. Le veo mucha utilidad para el latín (la:s:). Saludos. Lin linao ¿dime? 01:10 21 dic 2015 (UTC)

En realidad ya lo puedes hacer, simplemente añade la: antes del valor que vayan a tomar s y scap (el orden habitual de los prefijos es proyecto:código_de_idioma:título_de_la_página). Tal vez vendría bien crear salt para poder mostrar un texto alternativo en el enlace al que apunte s (de manera similar a scapalt). Un saludo, Peter Bowman (discusión) 01:22 21 dic 2015 (UTC)

buena idea, agregué el parámetro |salt=<título alternativo al que proponen en wikisource>|

y lo apliqué en mensú (título del libro citado no lleva coma) --Ninud (discusión) 12:07 22 dic 2015 (UTC)

¿Podrías hacer el favor de previsualizar antes de guardar los cambios —el botoncito bajo la sección «Vista previa de la página con esta plantilla»—? Ahora todas las demás plantillas que se basan en {{cita libro}} tienen un .» extra tras el año (cf. {{DLE}}). —Born2bgratis (discusión) 12:36 22 dic 2015 (UTC)

perdón, pequeño error de copy-paste. gracias por avisar, aunque también lo podrías haber hecho en un tono más cordial --Ninud (discusión) 13:18 22 dic 2015 (UTC)

Password Strength RFC

Hola,

Hemos iniciado una solicitud de comentarios en Meta para incrementar los requisitos de contraseña para usuarios que posean cuentas que puedan editar MediaWiki:Common.js o tengan acceso a las herramientas de verificador de usuarios o de supresión de ediciones.

Estos tipos de cuentas tienen acceso sensible a nuestros sitios y pueden causar un gran daño si caen en malas manos. Actualmente, el único requisito es una contraseña de, al menos, una letra. Nos gustaría hacer que el mínimo sea de 8 letras (bytes) y, además, nos gustaría prohibir algunas de las contraseñas más comunes.

Al incrementar los requisitos en las contraseñas para las cuentas con altos niveles de acceso, esperamos hacer a los wikis de Wikimedia más seguros para todos. Lee el texto completo de la propuesta aquí y hazte escuchar en la solicitud de comentarios.

Muchas gracias,

(En nombre del equipo de seguridad de la Fundación Wikimedia) BWolff (WMF) (discusión) 07:39 21 dic 2015 (UTC)

Entregado usando la distribución global de mensajes y la lista de distribución

Tech News: 2015-52

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

Noticias Técnicas

• Debido a las festividades, la siguiente publicación de las Noticias Técnicas se realizará el 11 de enero de 2016.
• Los escritores del boletín técnico solicitan tu opinión. ¿Obtuviste la información deseada durante este año? ¿Olvidamos publicar acerca de noticias técnicas importantes en 2015? ¿Qué tipo de información fue enviada muy tarde? Dínoslo. Puedes escribir en tu idioma. ¡Gracias!

Cambios recientes

• CompletionSuggester es nuevo algoritmo de sugerencias para Buscar. Está disponible como función en prueba desde el 17 de diciembre (más información).
• El Equipo Multimedia está ejecutando un test A/B para la herramienta multiwiki de subida. Están probando cuatro interfaces diferentes. El test se ejecuta desde el 16 hasta el 23 de diciembre (más información).

Cambios de esta semana

• No habrá despliegues de MediaWiki sino hasta el 12 de enero de 2016 (calendario).

Reuniones

• ¿Es requerido que los administradores y otros usuarios de herramientas avanzadas tengan contraseñas más fuertes? Puedes discutirlo en una solicitud de comentarios.
• No habrá reuniones del Equipo del Editor Visual el 22 ni el 29 de diciembre ni el 5 de enero.

Noticias técnicas preparadas por embajadores técnicos y publicadas mediante un bot • Contribuye • Traduce • Obtén ayuda • Comenta • Suscríbete o desuscríbete.

18:29 21 dic 2015 (UTC)

Noticias destacadas de Wikimedia, noviembre de 2015

Estos son las noticias destacadas del blog de Wikimedia de noviembre de 2015.

• El servicio de inteligencia artificial provee a los wikipedistas «gafas de rayos x» para ver a través de ediciones erróneas.
• Comité de Diseminación de Fondos de Wikimedia: cómo distribuir el dinero justamente en un movimiento global
• Revisa estas nuevas funciones y extensiones que se iniciaron en el Verano de Código de Google de 2015.
• En breve

About · Subscribe · Distributed via MassMessage (wrong page? Correct it here), 20:25 23 dic 2015 (UTC)

Introducción de la herramienta Corpus para lemas ignorados por la RAE

cómo justificar lo que no necesita justificación, me pregunto. no imaginé tener que hacer esto, pero, dada la ferviente oposición de Lin linao, allí vamos...
en la página de discusión de Wikcionario:Referencia/ES hace poco más de media década un tal Pablo323 pregunta: "¿para qué está esto?"
a lo que a pocas horas se le responde de forma categórica: "para ser material de apoyo al diccionario." firmado por el mismísimo Lin linao :)

1. Incumbencia de un corpus para lemas no tratados en otras obras lexicográficas

en la página de la RAE se presentan los recursos ordenados por importancia (nota bene: no alfabéticamente, y ubicando a los córpora en segundo lugar):

• Diccionarios (DLE, DRAE, DPD, etc.)
• Banco de datos (CORDE, CREA, CDH, CORDE, etc.)
• Gramática (nueva y primera)
• Ortografía (2010 y primera)
• Biblioteca
• Enlaces externos

si la existencia de las páginas de referencias y subpáginas (gramática, ortografía, etc.) del español en wikcionario están justificadas, la de corpus la supera en incumbencia.

2. ¿Por qué no aprovechar Wikiquote o Wikisource?

podemos aprovechar citas de ambos proyectos, aunque, en lo que concierne a este corpus, de manera muy limitada.

• Wikiquote es, como se explica allí, una colección de citas y frases famosas (es posible encontrarse con frases que incluyan algún lema ignorado o descalificado por la RAE, pero, en general se tratará más bien de casos excepcionales.
• Wikisource sería el equivalente wikimediano al Banco de datos de la RAE. aunque limitado, ya que, para no infringir contras los derechos de autor, solo puede acoger obras en dominio público.

3. ¿Cómo funcionan los córpora de la RAE?

sin permitirse el acceso para la lectura de la obra completa (protegiendo así los derechos de autor), sí se permite el acceso hasta los párrafos en el contorno del lema buscado, por cierto, con citas bastante más extensas de lo que generalmente sería necesario para el estudio del lema. (de la misma o similar forma parece funcionar el buscador dentro de google.books).
pero claro, por las características de los proyectos wikimedianos no hay forma de crear un circuito de datos cerrado de aquel tipo, que aquí todo es público.

4. ¿Cómo entonces emular un corpus en Wikcionario sin infringir contra los derechos de autor?

en Wikcionario, como en todas partes (tesinas, tesis, ensayos, libros, etc., y como en los mismos ejemplos que venimos exigiendo): citando, respaldándose en los derechos de cita, con esmero, dentro de una subpágina prácticamente invisible con un formato lema/XX/Corpus (XX = código de lengua) o similar.

• prácticamente invisible porque puede existir únicamente si el lema también existe. y si existe el lema y se lo busca, por ejemplo, sapucai, el buscador lleva directamente a la entrada del lema, quedando la subpágina de corpus sapucai/ES/Corpus solo accesible bajo un enlace especial dentro del lema.

sería consiguiente la creación de una categoría que enumere lemas que cuenten con este tipo de corpus.

5. ¿Será obligatorio para lemas que no figuren en otros diccionarios?

¡no! seguirá vigente la exigencia de al menos una cita. la creación del corpus para un lema será optativa. (lógicamente y por incumbencia deberían ser más de una las citas requeridas para defender la existencia de un lema no atendido en otros diccionarios, y cuantas más mejor. pero esto queda para algún voto futuro.

6. Pero entonces ¿para qué?

• vuelva al inicio y lea la cita de Lin :)
• ¡por amor al arte! :)
• pero en verdad, para adelantarnos a lo que tarde o temprano sucederá, que tendremos todas las acepciones aceptadas dentro de los diccionarios más comunes (temprano si alguien logra programar un bot para transcribir el archivo .djvu o .djvu.txt del DLC 1914)... y entonces ¿qué haremos? :)
• para darle un salto cualitativo al lema en cuestión, sujetando las acepciones a informes estadísticos colectados en el corpus
• en fin, y ningún secreto, porque así es como se redacta un diccionario...

7. Objeciones, preguntas, comentarios, etc.

espero haber quitado todas las dudas, pero si alguien tiene objeciones, le queda alguna pregunta o quiere hacer algún comentario, por favor, hágalo aquí indicando el punto al que refiere. gracias. --Ninud (discusión) 13:35 27 dic 2015 (UTC)

Mis objeciones ya están planteadas en la sección en que propusiste la idea y en la subpágina del sapucai. Las repito en corto: 1) no corresponde darle tratamiento especial a las palabras que no salen en el DRAE u otros diccionarios bien conocidos/no corresponde darle tratamiento especial al DRAE y otros diccionarios bien conocidos (se relaciona con la política de "Punto de vista neutral"), 2) el Wikcionario es un diccionario, estas colecciones de citas quedan fuera del propósito del proyecto, 3) el Wikcionario tiene licencia libre, que permite toda clase de usos mientras se cumpla con la atribución y el compartir igual, no solo los docentes o de investigación que admite el derecho de cita (y no se ha aprobado una política de excepción como la que tiene en:wikt, pensada para imágenes). Saludos. Lin linao ¿dime? 15:53 27 dic 2015 (UTC)

1) para asegurar el punto de vista neutral en wikcionario exigimos tratamiento especial para lemas que no figuren en ningún diccionario pidiendo al menos un ejemplo de la literatura o de otro medio oficial ({{cita requerida}}), que, aunque no nos quede duda de la buena fe del autor, debemos ser objetivos, que de otro modo cualquiera puede inventar lo que quiera.

por otra parte se pueden crear subpáginas de corpus para cualquier lema, como decía, queda en manos de los editores.

además el punto de vista neutral (véase también artículo en Wikipedia) refiere a propiedades cualitativas de la información, que, por el contrario de tu argumentación (Falacia de dirección incorrecta), cuantos más los puntos de vista, mayor el grado de neutralidad. de hecho, es lo que busca un corpus lingüístico, que cuanto mayor la cantidad de referentes en una estadística, mayor la probabilidad de acierto, y en el caso de una acepción ayuda a asegurarla. (como se puede ver en sapucai/ES/Corpus encontré un ejemplo que aplica al lema en el sentido original, como se usa en guaraní, de "grito" (arriba de todo), pero, un solo caso es insuficiente como para incluir la acepción en la entrada principal.)

2) los córpora son la esencia de los diccionarios (nuevamente, falacia de dirección incorrecta). por motivos obvios los de papel no los incluyeron. pero ahora, en la era digital, los diccionarios en línea comenzaron a ponerlos a la disposición del público. el DWDS hasta los incluye automáticamente a las búsquedas, ver por ejemplo Objektivität, abajo de todo incluye todas las concordancias en varios de sus córpora (permitiendo activar más si se desea, bajo "+Ressourcen"). la RAE no los incluye automáticamente en el diccionario, pero se pueden consultar separadamente, lo mismo y más accesible también en el CNRTL bajo concordance, ver por ejemplo concordance.

3) no hay problemas legales mientras se cumpla con los requisitos de derechos de cita (falacia del hombre de paja que encima abusa de una premisa errónea), lo que ya se viene aplicando en wikcionario hace tiempo, y está todo bajo Restrictions, el punto 4 en Creative Commons, y muy bien explicado, por ejemplo, en el artículo de wikipedia sobre los derechos de autor bajo Contenidos no libres: Política de Doctrina de Excepción.

nota sobre el uso de falacias al argumentar: entre personas cultas en general se las puede tomar como ofensas, ya que el que las aplica podría estar insinuando la falta de inteligencia de su contraparte. no estoy ofendido. no creo que haya sido tu intensión, que, en verdad, parece ser bastante obvio que ocurrieron por no investigar, pero, en fin, son lo que son...

me gustaría saber que opinan los demás. alguna crítica constructiva? mejoras? alguna duda o pregunta? saludos --Ninud (discusión) 17:06 28 dic 2015 (UTC)

• 1) No es cierto que haya tratamiento especial. A toda entrada se le piden referencias y ejemplos de uso. Esas referencias pueden ser diccionarios como el DRAE o no.
• 2) Valdría la pena consultar a la Fundación Wikimedia cuán admisible es almacenar esto, desde el punto de vista del alcance del proyecto (de paso también de los derechos de autor).
• 3) En el punto 4 de la licencia no encuentro eso, ¿podrías copiar la oración o párrafo? La licencia libre del Wikcionario permite hacer lo que sea con el contenido, mientras se cumplan ciertos términos, mientras que el derecho de cita exige ciertos fines o ciertos comportamientos, como la extensión o la integridad de la cita (es decir, las entradas del Wikcionario con ejemplos no libres tienen partes que no pueden usarse de acuerdo a la licencia, pero no se avisa en ninguna parte cuáles son o cómo se pueden usar). La Doctrina de Excepción la aprobó Wikipedia en castellano hace como un mes y no se ha implementado. El Wikcionario es un proyecto independiente y hasta ahora no existe algo parecido. Saludos. Lin linao ¿dime? 17:59 28 dic 2015 (UTC)

1)

normal: citar acepción de otro diccionario.

especial: justificar una acepción a partir de su uso en la literatura (u otros medios oficiales), que puede ser un ejemplo, pueden ser dos, veinte, o todos los que el usuario crea necesario (cuantas más sean las concordancias más asegurado el punto de vista neutral)

2)

buena idea :) ni bien lo haga y tenga respuesta lo público.

3)

bajo 4. Restrictions, 4.c.

«If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties;»

Original Author: en nuestro caso, nosotros, los editores de wikcionario.

another party or parties: terceros, en nuestro caso los autores de las citas.

básicamente dice que si vas a distribuir el artículo (en nuestro caso la entrada de un lema) debés mantener intacta toda la información sobre el copyright para dicho artículo, es decir, si existe, el nombre o seudónimo del autor original (un editor de wikcionario) y si este hace mención de un tercero (por ejemplo, un patrocinador, una entidad dentro de la industria editorial, un diario. y en nuestro caso el autor de la cita) también mencionarlo a este.

antes, bajo 2. Fair Dealing Rights:

«Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.»

traducción: Nada dentro de esta licencia pretende reducir, limitar o restringir cualquier uso libre de derechos de autor (como obras en el dominio público) o derechos originados de limitaciones o excepciones (como los derechos de cita) proveídas en relación a la protección de los derechos de autor bajo la ley de los derechos de autor u otra ley aplicable.

es decir, mientras que nos amparemos en los derechos de cita (cumpliendo con todos los requisitos), quedamos (nosotros, como wikimedia) libres de culpas

o en otras palabras: se hace culpable el que cita incorrectamente de wikimedia lo que en wikimedia se encuentre correctamente citado.

más allá de eso, y por encima, lo que se encuentre dentro de los parámetros de cita queda excluido de cualquier licencia que el autor dé de su obra, y me resulta extraño tener que defender este principio, las comillas de la cita excluyen lo que se encuentre entre ellas del resto de la obra... que por definición es lo que señalan.

pero ahora entiendo a lo que te referís. lo hubiera entendido antes si agregabas un link, y en general, tus argumentos tendrían mucho más peso si agregaras enlaces (no solo para convencernos a nosotros, si no que para cerciorarte vos mismo de que no estas argumentando falazmente, al menos para minimizar las falacias, que aún así ocurren, al menos a mi ^^), el único link que diste, aquí, en la página de discusión del corpus de sapucai y más arriba en el café donde propuse la idea por primera vez, es un link a una página vacía: en:wikt.

te referías a la Licensing policy (política de concesión de licencia), que el Board of Trustees de wikimedia votó y aprobó para que se aplique en todos los proyectos de wikimedia... en marzo del 2007!

el punto 6 es importante para nosotros (Peter Bowman, Lin linao, Esceptic0, Born2bgratis, Romanophile, Marrovi, etc.), ya que no contamos con una "Política de Doctrina de Excepción (PDE)", en cambio sí muchas citas infringiendo contra la resolución:

«En los proyectos que no tengan una PDE por el momento, se tomarán las siguientes acciones:

• A partir del 23 de marzo de 2007, todo el material nuevo bajo una licencia no aceptable deberá ser borrado.
• La Fundación decide apoyar a todas las comunidades que decidan desarrollar una PDE en tal proceso de desarrollo.
• Para el 23 de marzo de 2008, todos los archivos existentes bajo una licencia no aceptable deberán estar comprendidos por una PDE o ser borrados inmediatamente.»

en consecuencia a este "overkill" de comprensible paranoia legal, deberíamos votar sobre la implementación de una PDE (que sería algo así Contenidos no libres) con relativa urgencia (relativa porque si hasta ahora nadie se preocupó en insistir...). que si no por respeto a la resolución tomada, que sea para proteger las cientos, si no miles, de citas textuales no libres que se fueron juntando en wikcionario a través de los años, y así todos los lemas y acepciones no verificables de otro modo.

si nadie se me adelanta (y agradecería si alguien lo hace) me encargaré mañana.

--Ninud (discusión) 14:12 29 dic 2015 (UTC)

estaría bien marcar los ejemplos no libres con un "®", simplemente lo agregamos por defecto en la plantilla y si alguien usa un ejemplo libre se le agrega un parámetro para que no lo agregue, el listado de ejemplos no sería otra cosa que una plantilla de ejemplos expandida para neologismos y lemas controversiales. No estoy de acuerdo que sea requerimiento para cosas que no esten en el DRAE--Esceptic0 (discusión) 23:21 28 dic 2015 (UTC)

buena idea, aunque no estoy seguro de que "®" sea aplicable para estos casos.

importante: es completamente optativo! :) no puedo ni debo dejar de repetirlo, que sería una absoluta locura exigir que sea requisito, que son horas, si no días de recolección de datos e investigación para un solo lema (sapucai me llevó más de 4 horas y apenas recolecté la mitad (aproximadamente) de las concordancias que figuran tan solo en los 3 diarios mencionados allí. es para el que desee darle más peso a algún lema excluido por la RAE. y quién sabe, tal vez ayude a que se los incluya en la próxima edición :) --Ninud (discusión) 14:12 29 dic 2015 (UTC)

Solo como nota: ® se utiliza para ciertas marcas registradas, no para obras protegidas por derechos de autor. Supongo que se refería al signo para derechos de autor (©) que tampoco sería procedente para marcar solo una porción del Wikcionario, pues estas citas contrastan en que tienen todos los derechos reservados, mientras que todo el contenido del Wikcionario está protegido por derechos de autor aun cuando se encuentre bajo licencias libres. --Allan Aguilar (discusión) 22:21 29 dic 2015 (UTC)

Si ese es, bueno el mismo puede enlazarse a una página de explicación hecha ad hoc --Esceptic0 (discusión) 01:20 30 dic 2015 (UTC)

8. Addendum: Derechos de cita

molesto, y bastante, por tener que perder el tiempo con algo que en suiza ya me habían inculcado desde el bachillerato (estricta e "hinchapelotezcamente"), me fui en busca de un modelo de "Política de Doctrina de Excepción (PDE)" para adaptarlo a los propósitos de wikcionario.
en la lista meta:Non-free_content#Wiktionary el único proyecto de wikcionario con una PDE es el inglés, Wiktionary:Non-free content criteria, que ahora veo, era lo que intentaba enlazar Lin más arriba :) ("meta:en:Wiktionary:Wiktionary:xxx" que si no le agarra la chiripiorca). la PDE allí se introduce:

«The English Wiktionary often quotes copyrighted works to prove the existence and use of terms in various languages. This is acceptable under United States copyright law. This policy does not address such quotations; it governs the use of other non-free content, including copyrighted images, audio clips, videos and other media files.»

Traducción:

El Wikcionario inglés a menudo cita obras protegidas por los derechos de autor para probar la existencia y el uso de lemas en varias lenguas. Esto es aceptable bajo la ley de derechos de autor de los Estados Unidos de América. Esta política no apunta a esas citas; gobierna el uso de otros contenidos no libres, como imágenes, archivos de audio, de video y otros archivos protegidos por los derechos de autor.

¡y punto!
el apartado B en las votaciones sobre la PDE en Wikipedia en español, Parte B. Establecer una Política de Doctrina de Excepción (PDE) en fragmentos de textos, en realidad, no era necesario, que, para citas textuales, los derechos de cita hacen una PDE obsoleta, que mientras se cite correctamente, se está señalando claramente que se trata de contenido no libre.
aún así voy a seguir el consejo de Lin, y me pondré en contacto con el departamento legal de wikimedia a ver si se justifica crear apartados de corpus (o de citas numerosas).
y por otro lado, no vendría mal implementar una PDE para poder incluir imágenes u otros archivos bajo ©. --Ninud (discusión) 12:07 30 dic 2015 (UTC)

Sí, la ley estadounidense acepta el fair use. Para mí, el objetivo principal de aclarar las partes no libres es ayudar al reutilizador del contenido, para quien se supone que trabajamos. En los países de habla hispana no hay tradición de fair use, pero vi que Perú lo considera al hablar de lo que se permite hacer con las citas y que Chile permite varias cosas mientras "se hagan a título de cita". De todas maneras, creo todas las legislaciones exigen la integridad y eso ya no es contenido libre como el resto de las entradas. En este momento no puedo extenderme, en otro comentario desarrollaré la idea para marcar el contenido de forma sencilla. Saludos. Lin linao ¿dime? 13:50 30 dic 2015 (UTC)

señalar columnas

¿existe algún símbolo como el calderón ¶ o parágrafo § para señalar columnas en vez de párrafos? es para referenciar mejor el DRAE1914--Esceptic0 (discusión) 16:39 29 dic 2015 (UTC)

disculpá la demora en responder. no, que yo sepa, no tenemos nada por el estilo. con la plantilla de referencia {{DLC1914}} podés agregarle el número de página, el lema y la fecha de la consulta (esto último innecesario, que se trata de una obra que no va a cambiar). igual alcanza poniéndole la página... que tanto más rápido no se va a encontrar con el número de columna ;) --Ninud (discusión) 09:21 31 dic 2015 (UTC)