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>

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 marzo 2024

Tabla de conjugación

Por alguna razón la tabla de conjugación está abierta por defecto, cuando debería estar plegada, también debería poderse hacer algo así con las de traducciones, como en en.wikt. Rodrigo5260 (discusión) 01:53 1 mar 2024 (UTC)

Cuál tabla de conjugación? Tmagc (discusión) 02:45 1 mar 2024 (UTC)

La de los verbos en español. Rodrigo5260 (discusión) 16:46 1 mar 2024 (UTC)

O eso solo pasa en móvil y en la pc se ve normal? Rodrigo5260 (discusión) 16:47 1 mar 2024 (UTC)

Es sólo para los teléfonos. En PC se ve bien. PArece que la función de plegar elementos no es compatible con móviles. No hay mucho que se pueda hacer. Tmagc (discusión) 17:09 1 mar 2024 (UTC)

Puedo adaptar el código para que funcione en dispositivos móviles, pero preferiría primero migrar el sistema actual al mismo que emplean {{trad-arriba}} y {{rel-arriba}}, añadiendo la clase "mw-collapsible" a la cabecera. Peter Bowman (discusión) 21:58 1 mar 2024 (UTC)

@Peter Bowman Es buena esa, pero de todas formas las cajas de traducciones no se muestran plegadas, o al menos a mí no me aparece la posibilidad de hacerlo. Tmagc (discusión) 01:34 2 mar 2024 (UTC)

@Tmagc: eso es un poco raro, la de traducciones se te debería mostrar inicialmente plegada como aquí. Ese mecanismo, y por eso lo prefiero, viene del propio MediaWiki, así que está habilitado por defecto para todo el mundo. Sí que puede pasar que las tablas de conjugaciones no se te plieguen si has deshabilitado antes el accesorio "Añade botones globales de plegado/desplegado para tablas y plantillas." Peter Bowman (discusión) 11:13 2 mar 2024 (UTC)

Además, ¿no sería mejor ir pensando en un estilo que permita mover la plantilla arriba, para quitar la sección de conjugaciones y uniformizarlo tal como es en sustantivos o adjetivos? Tmagc (discusión) 02:02 2 mar 2024 (UTC)

Puede ser, no he entrado a valorar si conviene migrar o no. Hay que recordar que las conjugaciones tienden a ocupar mucho más espacio y que posiblemente por ello tengan su propia subsección. Tampoco es bueno meter todos los sustantivos y adjetivos en el mismo saco porque en unos casos con poner un par de formas basta (el plural en las lenguas romances no exige más), y en otros hará falta rellenar una tabla con bastantes filas y columnas (en aquellas lenguas altamente flexivas). No me preocuparía tanto por homogeneizar como por tratar de que se facilite la visualización y lectura de las entradas en el mayor número de casos; aquí me gusta cómo lo han solucionado en enwiktionary, donde siempre que necesiten incluir una tabla la separan en su propia sección (de conjugación o flexión sustantiva/adjetiva). Peter Bowman (discusión) 11:23 2 mar 2024 (UTC)

Pares mínimos

Sólo para saber: sería lo adecuado eliminar estos ítems cada vez que aparezcan? Estoy pensando en lo que aparece en amar. No veo que agregar este tipo de información sea una contribución significativa. Lo mismo diría de los anagramas. Sea cmo fuere, si vamos a mantener la posibilidad de incluír esta información debería estar en una plantilla para tal fin {{pares mínimos}}. Tmagc (discusión) 16:05 2 mar 2024 (UTC)

Yo no les veo utilidad. Incluso los anagramas no dejan de ser una mera curiosidad, tal vez útiles para gente que se dedica a los juegos de palabras. Allá por el 2012 y posteriormente en 2018 hablamos de sacar esa información e integrarla en una herramienta web externa a modo de buscador de anagramas: Wikcionario:Café/2018 09#Propuesta sobre anagramas. O eso, o automatizarla con un bot, como propuse en su día. Peter Bowman (discusión) 16:14 2 mar 2024 (UTC)

@Peter Bowman Tendría que estudiar esa “herramienta externa”. Si es un buscador, y permite recolectar todos los anagramas de una palabra en base a las entradas existentes, entonces me quedo con esa opción. Lo de tener un bot que automatize esa parte creo que es más difícil porque en primer lugar necesitaríamos que todas las páginas estén impecables, aún faltan unas cuantas y por ahí las irregularidades en el formato imposibilitan el parseo. Además, qué pasa si alguien se pone a toquetear eso y bloquea al bot? Si podemos poner un enlace en la portada a ese buscador, nos sacamos un problema de encima y quedan las entradas mucho más limpias.

Pero a lo de los “pares mínimos” no le veo ninguna utilidad ni ninguna forma de automatizarlos porque se necesitaría tener las transcripciones fonéticas de cada palabra y hay unas cuantas irregulares que habría que completar manualmente. Tmagc (discusión) 16:37 2 mar 2024 (UTC)

Bot para actualizar plantillas

Tengo un bot que opera con la cuenta RoboJ2 y puede transformar la mayoria de los casos de uso de la plantilla obsoleta ejemplo_y_trad a la plantilla ejemplo, ¿hay alguna objeción para ejecutar este bot?, ¿le puedo asignar el atributo de cuenta del tipo bot? Cvmontuy ^(mensajes) 13:46 24 feb 2024 (UTC)

Enlacémoslo al menos: User:RoboJ2. @Cvmontuy: ¿en qué lenguaje de programación está escrito el bot y qué framework estás empleando? ¿Vas a lanzarlo de forma supervisada o completamente autónoma? Solo has realizado dos ediciones de prueba; haz, por favor, al menos un par de decenas más para que veamos qué tal se las apaña en el espacio de nombres principal. Si no hay problemas, en una semana le asigno el flag. Aviso a Tmagc (autor de la nueva versión de {{ejemplo}}) por si observa algo en Especial:Contribs/RoboJ2. Comentario adicional: no le veo sentido a la plantilla {{NKJV}}, solo sirve para rellenar uno de los muchos parámetros de esta plantilla. Peter Bowman (discusión) 14:58 24 feb 2024 (UTC)

Por enlace te refieres a la pegatina, en la página de usuario del bot?(listo).

Favor de ver respuestas en la pagina del usuario en cuestión.

Esa plantilla NKJV, a mi me permite tener una lista de entradas para un proyecto personal Cvmontuy ^(mensajes) 17:08 24 feb 2024 (UTC)

Gracias, acabo de ver la página del bot. En cuanto a la plantilla NKJV, si es algo que solo te sirve a ti, preferiblemente usa por favor tu espacio de usuario (por ejemplo, guarda las entradas pertinentes en una lista). Peter Bowman (discusión) 19:19 24 feb 2024 (UTC)

¿Esta bien, si hago que el bot retire {{NKJV}}, después de terminar, la migración de la plantilla {{ejemplo_y_trad}}? Cvmontuy ^(mensajes) 19:40 24 feb 2024 (UTC)

Yo lo haría durante la migración, guardando las páginas donde se habría usado esta plantilla, pero si lo prefieres, déjalo para después. Peter Bowman (discusión) 20:37 24 feb 2024 (UTC)

@Cvmontuy Pero sabés cómo funciona la nueva plantilla? La plantilla que está ahora cambió los parámetros respecto de cómo era antes. Si estás con Python esto [1] es algo similar a lo que esperaría que corras. Como podés ver no es tan trivial la migración porque hay muchos parámetros que cambiaron de nombre. Otros, como el apellido y el nombre o el año, mes o día se unifican en uno solo (el autor o la fecha). En otros casos, hay que dividir porque aparecía por ejemplo en la fecha algo como fecha=1980 [1555], y ahora debería ser |f=1980|fo=1555. Yo últimamaente estoy muy ocupado, pero cuando tenga un rato libre me pongo de nuevo a ver cómo seguir con las migraciones de las plantillas. Agarrá de a lotes de páginas y fijate qué es lo que aparece, cuáles son los errores que se repiten y cómo deberías corregirlo. Porque si lo único que hacés es cambiar el nombre de la plantilla, el módulo de {{ejemplo}} va a arrojar un error. Básicamente por eso es que no quiero seguir migrando así nomás sin dedicarle un poco más de tiempo para estudiar el tema. Revisá lo que hice últimamente con mi TMCbot. Saludos Tmagc (discusión) 23:18 24 feb 2024 (UTC)

De acuerdo, estuve revisando las pruebas con tu bot, y salvo por lo de NJKV, el resto está OK. Por lo que infiero, vas a usar el bot para migrar tus propias contribuciones y ya conocés bien cómo las hiciste. Pero no invalida lo que dije antes: si vas a migrar páginas de otros, con mucho cuidado porque los estilos con los que uno se encuentra son muy heterogéneos. Tmagc (discusión) 02:39 25 feb 2024 (UTC)

@Tmagc, gracias por revisar, saludos, 200.68.186.243 (discusión) 20:39 25 feb 2024 (UTC)

¿Puedo poner a RoboJ2 el flag de bot? --Cvmontuy ^(mensajes) 12:12 1 mar 2024 (UTC)

@Cvmontuy, mañana se cumplirá una semana y le asignaré el flag. Si te urge, edita hoy esas 300 páginas que faltan (ya llevas 170 ediciones de prueba) y prescindiremos de asignar permisos. Peter Bowman (discusión) 15:38 1 mar 2024 (UTC)

@Cvmontuy: ahora se los asigno. Ten en cuenta, por favor, mw:API:Etiquette e intenta poner una pausa de al menos 5 segundos entre cada edición del bot. Cuando vayas a ejecutar una nueva tarea, abre un hilo aquí, descríbela y espera un tiempo prudente para permitir posibles observaciones. Un saludo, Peter Bowman (discusión) 16:07 2 mar 2024 (UTC)

Gracias Cvmontuy ^(mensajes) 10:50 3 mar 2024 (UTC)

@Cvmontuy: ya que lo tienes, ¿por qué no usas el flag? Acabas de hacer unas 150 ediciones sin él, dejándolas visibles en los Cambios Recientes. Peter Bowman (discusión) 12:21 3 mar 2024 (UTC)

Hola una disculpa, no sábia que se tenia que activar una bendera en el código del bot, ya lo hice, gracias Cvmontuy ^(mensajes) 01:07 4 mar 2024 (UTC)

Bueno, ya pasó una semana así que podrías darle el flag y que le meta rosca nomás. Tmagc (discusión) 16:07 2 mar 2024 (UTC)

Para el próximo fin de semana quitare la plantilla NKJV, ¿Debemos borrar las plantillas obsoletas, sin uso en entradas del wikcionario? --Cvmontuy ^(mensajes) 11:55 4 mar 2024 (UTC)

Creo que sería más aconsejable categorizarlas con {{plantilla obsoleta}} en la documentación o también en la plantilla misma con noinclude. Aunque si la plantilla implica un vicio para la comunidad en general se podría además de eso comentar el código para evitar que la sigan usando... Tmagc (discusión) 14:37 4 mar 2024 (UTC)

Estaría bien categorizar las entradas que transcluyen plantillas obsoletas, para su posterior revisión. NKJV excepcionalmente se borrará, y deberíamos evitar crear este tipo de plantillas de un solo uso para fines particulares. Peter Bowman (discusión) 21:45 4 mar 2024 (UTC)

Noticias técnicas: 2024-10

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

Cambios recientes

• La página Special:Book (asociada a la funcionalidad de "Crear un libro") que se genera por el uso de la antigua extensión de Colecciones fue eliminada de todas las wikis de Wikisource debido a que no funcionaba correctamente. Esto no afecta la capacidad de descargar libros, la cual es provista por la extensión de Wikisource. [2]
• Wikitech está usando la próxima generación de Parsoid en forma predeterminada para generar todas las páginas en el espacio de nombre Discusión. Reporta cualquier problema en la página discusión de Problemas Conocidos (Known Issues). Puedes usar la extensión ParserMigration para controlar el uso de Parsoid; mira la documentación de ayuda para más detalles.
• El mantenimiento en etherpad esta completo. Si encuentras algún problema, por favor indícalo en esta tarea en Phabricator.
• Los Accesorios (Gadgets) permiten a los administradores de interfaz crear características y funcionalidades con CSS y JavaScript. Los espacios de nombres Gadget y Gadget_definition y el permiso de usuario gadgets-definition-edit fueron reservados para un experimento en 2015 pero nunca fueron utilizados. Estaban visibles en la página de búsqueda y permisos de usuarios. Los espacios de nombres y permisos de usuarios sin uso fueron eliminados, sin generar cambios o la necesidad de mover páginas. [3]
• Se realizó una una mejora de usabilidad en el flujo de "Añadir una cita" en Wikipedia, moviendo el botón de inserción al encabezado del popup. [4]

Cambios durante esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 5 de marzo. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 6 de marzo y en todas las wikis a partir del 7 de marzo (calendario). [5][6]

Cambios futuros

• Todas las wikis estarán en modo solo lectura por algunos minutos el 20 de marzo. Está previsto que esto ocurra a las 14:00 UTC. Se publicará más información en las Noticias Técnicas y de manera individual en cada wiki durante las próximas semanas. [7]
• El código HTML de los enlaces de edición de los encabezados y secciones será cambiado más adelante durante este año para mejorar la accesibilidad. Lee los cambios en esta página para más detalles. Este nuevo código será el mismo que en el nuevo codificador de Parsoid. Puedes hacer pruebas de tus accesorios u hojas de estilos con este nuevo código si añades ?useparsoid=1 a tu URL (más información) o activas Parsoid en tus opciones de usuario (más información).

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

MediaWiki message delivery 19:47 4 mar 2024 (UTC)

Etimologías en palabras compuestas

Hola. Una de las cosas que quedan por discutir es sobre los criterios que deben emplearse para {{etimología}} con locuciones y frases. Hasta el momento, con @Peter Bowman y @PFSV-UY tenemos considerados tres casos que parecen ser bien heterogéneos o quizá imposibles de categorizar de la misma forma: mundo sublunar, Burkina Faso y leche de almendras. Para redondear lo que se estuvo discutiendo, la propuestas serían las siguientes (no necesariamente excluyentes):

• Usar {{etimología|suma}} que podría servir para mundo sublunar y también para leche de almendras ya que la etimología podría considerarse la suma de las partes (pero no la definición). Se genera la leyenda “Consulte las etimologías de cada palabra por separado”
• Categorizar como las demás entradas cuando sea posible y cuando no lo sea dejar la plantilla vacía --> es lo que no queremos porque quedarían miles de entradas con la plantilla vacía cuando en muchos casos ni tiene sentido completarla.
• Categorizar como las demás entradas cuando sea posible y de lo contrario omitir la sección. Esta opción es la que probablemente elija la mayoría, ya que suena más lógico del lado de la edición. El problema es que podría traer algún inconveniente del lado de los bots al parsear los sitios ya que al incluírla siempre a la sección con la plantilla, éstas vienen a ser como un punto que se puede tomar como referencia para saber que el formato de la página es el correcto.
• (nueva propuesta mía) Similar a la tercera, pero en lugar de omitir la sección, incluírla con {{etimología|n/a}} y que muestre literalmente el título de etimología y abajo “N/A”. Esto funcionaría similar a {{pron-graf|pron=no}}

Mi voto es por la cuarta opción excluyendo todas las demás, porque también contempla a la primera. Este argumento “suma” lo podríamos dar de baja porque tal vez se genere algún mal entendido y comiencen a pensar que avalamos que escriban frases que son la mera suma de las partes. Tmagc (discusión) 02:51 5 mar 2024 (UTC)

Tu idea es buena, pero no sé si «N/A» sea el término ideal a utilizar, pues no es propio del español, si no del inglés "not avaliable/applicable", por lo que usarlo en Wikcionario en español no sé si sea la mejor idea, y no conozco alguna alternativa hispanizada. Por otro lado, no sé si queda bien estéticamente. PFSV-UY (discusión) 06:16 5 mar 2024 (UTC)

Respecto a la cuarta opción, temo un poco que alguien no sé dé cuenta de la intención original y empiece a añadir ese parámetro a entradas sin etimología que no son palabras compuestas. Aparte de eso, inevitablemente suscitará la duda, a lectores y nuevos editores, acerca de la necesidad de mantener ese aviso (si no se ha especificado, para qué indicarlo explícitamente). Por ello, mi otro temor es que dentro de unos años, cuando ya no estemos, se decida suprimir esa sección vacía como ya ocurrió otrora con la de "Acepciones". Tal vez sea menos lioso y más simple dejar una sección de "Etimología" sin plantilla en esos casos. Peter Bowman (discusión) 18:08 5 mar 2024 (UTC)

@Peter Bowman Me sonaría mejor algo así como {{etimología|ocultar}}. En cuanto a lo del problema de N/A, a mí no me preocupa tanto. Si es un anglicismo, tal vez cambiarlo por “No aplica” podría funcionar. Y en cuanto a de que no capten el propósito, por eso es que hay que mantener claras las documentaciones. Mi intención justamente es, una vez que cerremos estos últimos detalles de formato y comenzado con las migraciones, volver a redactar lo que sería la nueva guía de estilo. En lo posible que conste de una única página, así evitamos problemas en cuanto a las redirecciones y el seguimiento de todas las páginas. Allí se aclararían todos estos detalles, aunque también las explicaciones deberían ser breves y con enlaces a las documentaciones de las plantillas en lugar de volver a explicar las plantillas mismas allí. Lo que nos permitiría hacer más énfasis en que lean la guía de estilo porque llega un momento en que es cansador andar editando las ediciones de todo el mundo porque se salen de un supuesto “estilo pactado” del cual sólo uno o muy pocos saben exactamente qué es lo que se espera en cada caso. Tmagc (discusión) 19:57 5 mar 2024 (UTC)

No quiero sonar desalentador, pero de las pocas cosas que tenemos claramente documentadas y al día en WN:ES es la estructuración de las formas flexivas, y es al mismo tiempo la que más cuesta que la gente entienda y respete. Por eso tengo un bot que realiza mantenimiento diario: si alguien la lía (hasta cierto grado), tiene detrás a un autómata corrigiéndole y aplicando la norma. Es lo que va a tocar hacer también para este caso :). Peter Bowman (discusión) 23:07 5 mar 2024 (UTC)

El Informe de ratificación de la Carta del Comité U4C, así como la Convocatoria a Candidaturas, se encuentran desde ahora disponibles.

El presente mensaje se encuentra traducido a lenguas adicionales en Meta-wiki. Por favor, ayuda a traducir a tu idioma

Saludos a todos y todas:

Me dirijo a ustedes el día de hoy portando dos importantes datos informativos. En primer lugar, damos a conocer que el informe relativo a las observaciones a la ratificación de la Carta del Comité Coordinador del Código Universal de Conducta (Comité U4C). En segundo lugar, anunciamos que la convocatoria a candidaturas para integrar el Comité U4C está abierta, desde hoy hasta el día 1 de abril del presente año 2024.

El Comité Coordinador del Código Universal de Conducta (Comité U4C) es el equipo global destinado a implementar el Código Universal de Conducta de modo equitativo y consistente. Invitamos a los miembros de la comunidad a presentar su postulación para formar parte del mismo. Para conocer más información sobre el Comité U4C y sus responsabilidades, sugerimos revisar la esta revisión de la Carta del Comité U4C.

La carta dispone que el Comité U4C estará conformado por 16 miembros, distribuidos a razón de 8 miembros provenientes de la comunidad en general, y ocho miembros provenientes de las regionales del movimiento, a fin de asegurar que el mismo refleje la diversidad del movimiento.

Mayores informaciones, así como el espacio para presentar su candidatura, podrán encontrarse en Meta-wiki.

En nombre del equipo del proyecto del CdCU,

RamzyM (WMF) 16:25 5 mar 2024 (UTC)

Lenguas construidas

Creo que es mejor que nos enfoquemos en lenguas naturales antes que en las artificiales (el esperanto y el ido podrían ser excepciones), en el Wikcionario en inglés tomaron una decisión parecida hace tiempo. Rodrigo5260 (discusión) 22:28 6 mar 2024 (UTC)

Yo no veo cuál es el problema. El esperanto se usa actualmente en algunas regiones. Si está lo suficientemente atestiguado, todo puede valer. Traté de ser lo más amplio posible cuando armé la nueva lista de idiomas para que cada quién agregue de lo que más le plazca. A menos que hayas encontrado algún problema en particular, prosigamos con el asunto de acuerdo a como está actualmente. Saludos. Tmagc (discusión) 22:49 6 mar 2024 (UTC)

No creo que sea malo si un Wikipedista quiere centrarse solamente en lenguas artificiales, lo cual es mejor a que no colabore en absoluto, y después de todo, considero que tener un buen diccionario de una lengua artificial (con codigo ISO claro) puede atraer más gente al proyecto. Si tu quieres centrarte más en lenguas naturales está bien, así como que otros solo hagan artificiales. PFSV-UY (discusión) 22:44 7 mar 2024 (UTC)

Nuevo parámetro en pron-graf

Estoy intentando agregar los módulos de pronunciación automática para otras lenguas. Resulta que en algunas como el francés o el ruso la plantilla requiere parámetros adicionales, por ejemplo, el tipo de palabra porque en el francés la pronunciación cambia dependiendo de si es verbo; en el ruso es similar y además se puede especificar si es válido palatalizar la “z”, entre otras cosas adicionales que exceden a la grafía que se pasaría como |ayuda. Dos approachs: el primero que se me ocurrió consiste en usar una notación especial, algo así como |ayuda=aimerai[V] para el verbo aimerai, el segundo consistiría en agregar un parámetro nuevo a la plantilla tal que sea |ayuda=aimerai|ayudaextra=V. En este nuevo parámetro se pasan todos los flags adicionales que sean necesarios.

Personalmente prefiero el segundo, creo que es más fácil de mantener a largo plazo y más legible. Pero me gustaría saber cómo quieren resolver esto; y si están de acuerdo con mi propuesta, podemos llamarlo “ayudaextraN” para “ayudaN”, o bautizarlo como más les guste (un poco largo el nombre que se me ocurrió). Tmagc (discusión) 04:05 9 mar 2024 (UTC)

Hola, @Tmagc. Si he entendido bien, podríamos tener hasta N parámetros adicionales en función de la lengua a transcribir. ¿No añade esto más complejidad a la plantilla? En cualquier caso, confío en tu criterio. Peter Bowman (discusión) 11:36 9 mar 2024 (UTC)

@Peter Bowman El parámetro adicional en realidad es uno solo, que es una lista. Cada elemento tiene todos los flags necesarios. El i-ésimo elemento de |ayudaextra corresponde con el i-ésimo elemento de |ayuda. Entonces, por ejemplo suponiendo que se necesite especificar que es un verbo y que se puede palatalizar (o lo que fuere, estoy inventando) quedaría |ayudaextrai=vp. En cuanto a que sea necesario especificar el tipo de palabra no me preocupa porque es fácil automatizarlo con un bot. Tmagc (discusión) 13:06 9 mar 2024 (UTC)

Cambios en la plantilla de traducciones t+

Para evitar ambigüedades, propongo agregar un punto al final de las abreviaturas. Esto permitiría agregar la plantilla en las traducciones para las letras y quizá también en posibles traducciones de nota, etc. La nueva lista de abreviaturas está en la documentación. Tengan en cuenta que simplifiqué las que estaban antes, por lo que cosas como sust. & adj. o sust. y adj. ahora pasan a ser sa. En cuanto a como está ahora, que pasaría a ser un formato considerado obsoleto, no toquen nada, yo me encargo de migrar todo. Sólo les pido que, si no tienen nada para oponer, queda a partir de ahora implementado este cambio. Tmagc (discusión) 20:06 3 mar 2024 (UTC)

@Tmagc: cuando hablas de ambigüedades, ¿te refieres a que estas abreviaturas podrían coincidir con algún código de idioma? Para indicar que se trata de un sustantivo o adjetivo no me preocupa, pero el caso de las marcas de género m./f./n. estas son tan universales, que temo que los editores no lo respeten cuando ya estaban acostumbrados al estándar anterior; sobre todo si llegan de otro proyecto como enwiktionary donde también se usan estas abreviaturas, pero sin punto. Peter Bowman (discusión) 20:40 3 mar 2024 (UTC)

@Peter Bowman Me refiero a que coincidan con la palabra que se quiere traducir. ¿Cómo traducís la f al inglés (mirá cómo está ahora)? ¿Cómo traducirías nota al italiano, por ejemplo? Tmagc (discusión) 21:03 3 mar 2024 (UTC)

Vale, perdón, ya veo por dónde van los tiros. Casi preferiría jubilar ese monstruo que es la actual plantilla {{t+}} por algo más cercano a enwiktionary, véase en:cat/translations. Nuestro problema es que dicha plantilla intenta abarcar todo, desde el nombre del idioma hasta todas y cada una de sus traducciones, incluyendo la transcripción, género, notas, etc. Todos los parámetros son posicionales y un despiste hace que el conjunto se desbarate, aparte de esos posibles conflictos que has identificado. Si cada traducción va en su propia plantilla y en vez de reconocer el parámetro posicional "|nota|<valor>|" usamos el parámetro con nombre "|nota=<valor>|", ese problema se soluciona. Sería necesario usar una caja de traducciones por acepción, cosa que nuestro sistema soporta y que ya he visto aplicar a algunos de nuestros editores. Podríamos aprovechar también para integrar su interfaz de edición de traducciones (para no tener que entrar en el modo de edición de la página entera).

Si esto no resulta viable, preferiría cargarme el parámetro "nota" y similares en t+ antes que añadir ese punto, tener que editar miles de entradas y suponer que nuestros actuales y futuros editores se acordarán de ese detalle. No debería hacer falta especificar nada más aparte de la palabra traducida, su género gramatical y la transcripción si aplica, todo lo demás está en la entrada correspondiente. El último ejemplo de Plantilla:t+/doc ({{t+|de|amphibisch|a.|,|Amphibie|s.|,|Amphibium|s.}}) no representa un caso real; en esta situación, cada palabra va referenciada a una acepción diferente, por lo que no haría falta indicar si se trata de un adjetivo o un sustantivo. Igualmente, lo de traducir letras (respondiendo a tu siguiente comentario) no me parece una buena idea. No son traducciones, sino equivalencias, que entre idiomas y alfabetos se pueden respetar o no. Peter Bowman (discusión) 21:24 3 mar 2024 (UTC)

@Peter Bowman migrar el choclo de parámetros posicionales es relativamente fácil de hacer, puedo convertir todas las abreviaturas en no-posicionales y quedaría |g1=m, |g2=f, |nota1=(nota1), |nota2=(nota2), etc.. Pero cómo sería lo de poner varias cajas? Habría que escribir cada acepción en forma “resumida” y eso para cada página porque sería muy difícil de automatizar. Se me hace que es demasiado tarde para migrar algo como eso. A menos que hagamos una vaquita entre todos y contratemos un equipo de una 100 personas que reescriban las traducciones páginas por página (y de paso nos unifican todo el formato ya que estamos) xd. No, en serio, en suma lo primero ok pero lo segundo lo veo muy muy difícil. Tmagc (discusión) 21:34 3 mar 2024 (UTC)

Sí, lo comparto, sería tremendamente complejo. Lo único que se me ocurre es, de momento, obviar el resumen de cada acepción y simplemente poner su número en la caja. Si un bot puede parsear {t+} y entender la numeración que codifica, también será capaz de separar su contenido en cajas diferentes solo en base al número. Habría un montón de cajas a las que no sería capaz de asignar una acepción simplemente porque falta el número en {t+}, pero me quiere sonar que en enwikt también tuvieron ese problema. Sería una fase de transición que requeriría del esfuerzo humano para ordenar las traducciones, pero esa necesidad ya existe a día de hoy debido al uso descuidado de {t+} o de sus predecesoras. Con el tiempo, iríamos completando a mano esos resúmenes faltantes, y por supuesto, a la hora de añadir nuevas cajas, ya los tendríamos en cuenta. Peter Bowman (discusión) 23:41 3 mar 2024 (UTC)

@Peter Bowman Yo tengo cierta reticencia para hacerlo, dudo que quede bien porque por un lado hay que tener en cuenta que este sitio es infinitamente menos activo que en.wikt. La gente que entra a diario es muy poca, por lo tanto el día del arquero vamos a completar todas las cajas. Después, cómo sería el criterio? Estoy pensando en páginas como ser, que actualmente tiene 24 acepciones. Hacemos 24 cajas? o cómo las harías en ese caso? Yo creo que con los números es más fácil: si no se pone nada se da a entender que es un “equivalente perfecto” y si la traducción es para algunas acepciones se lo aclara. Pero lo de las cajas es ciertamente difícil determinar esos criterios, incluso para automatizar. Porque si te fijás por ejemplo en be o en otras páginas no siempre es uno a uno la relación entre acepción y caja.

Por eso, si no es a mano yo creo que es imposible. Si tuviéramos un equipo con el que contar de, ponele, 50 personas, con el que nos pusiéramos de acuerdo y pudiéramos decir “nos ponemos todos con esto”, ahí sí lo haría y en un mes o un poco más tendríamos todo migrado. Pero viendo que es muy poca la gente que participa regularmente, de los que participan son muy pocos incluso los que están al tanto de todos los últimos cambios hechos y siguen editando con formatos viejos. Entonces, por el momento no me convence hacerlo. Tmagc (discusión) 00:58 4 mar 2024 (UTC)

Mientras tanto, voy a reutilizar {{t}} (la disocié de {{trad}}), que tiene pocas páginas y voy a implementar allí la nueva versión en donde admita los parámetros no posicionales, a la vez que voy preparando el bot para que convierta las plantillas. En cuanto a lo segundo, por ahora está igualado. A menos que alguien más opine a favor, se mantiene el statu quo. Tmagc (discusión) 01:21 4 mar 2024 (UTC)

@Peter Bowman Creo que en en.wikt no traducen las letras a los equivalentes de otros idiomas como hacemos acá. Una opción sería prohibir las traducciones de letras equivalentes. Pero si es por mí, que sea problema de ellos. Es decir, cuando haya migrado todo el módulo les va a tirar error con un mensaje sugiriendo revisar la documentación de la plantilla. Que la lean y punto. Y si no saben leer castellano, mejor que ni editen entonces. Tmagc (discusión) 21:08 3 mar 2024 (UTC)

@Peter Bowman Plantilla:t te parece bien así o cambiarías algo? Como observación, esta versión en donde se fuerzan los parámetros adicionales a que sean no posicionales (pero sí indexados) se pierde un poco de flexibilidad ya que si la comparás con la Plantilla:t+ que iría a ser reemplazada, no va a ser posible quitar los links para una única palabra o especificar varias trasnliteraciones para una misma palabra. Por mí está bien esta nueva plantilla, creo que no son cosas que valga la pena conservar y se va a uniformizar más el formato. PEro confirmame así veo si puedo empezar a migrar algo ne algún momento. Saludos. Tmagc (discusión) 01:52 12 mar 2024 (UTC)

@Tmagc: ya que ahora van a abundar los parámetros con nombre, tal vez sea más seguro que las traducciones también vayan así: {{t|de|t1=Katze|a=1,2|g=f|t2=Kater|g2=m|a2=1|nota2=gato macho|t3=Tic Tac Toe|a3=8}}. El riesgo es que alguien haga {{t|de|Katze|Kater|Tic Tac Toe|nota2=gato macho|g=f|g2=m|a=1,2|a2=1|a3=8}} (u otro tipo de permutación mucho más aleatoria que esta) y luego se equivoque al asociar traducciones a parámetros opcionales cuando su número sea muy elevado. Es algo que he observado en {{uso}}, {{ámbito}} y similares: llega un editor, borra lo que no debe, la nota pasa a referirse a otra acepción, otros editores hacen más cambios sobre eso y el error se mantiene (o empeora), perdiéndose lo que se quiso transmitir en un principio. Peter Bowman (discusión) 23:28 12 mar 2024 (UTC)

@Peter Bowman De acuerdo, ya cambié la plantilla. Ahora debería estar lista para ser usada. Tmagc (discusión) 01:00 13 mar 2024 (UTC)

Noticias técnicas: 2024-11

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

Cambios durante esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 12 de marzo. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 13 de marzo y en todas las wikis a partir del 14 de marzo (calendario). [8][9]
• Tras consultar con varias comunidades, el alto de línea del texto en la piel (skin) de Minerva será aumentado hasta los 1.65. Existen diferentes opciones de tipografía que pueden ser configuradas en las opciones del menú por si es necesario. [10]
• El color del enlace activo en Minerva será cambiado para ser consistente con nuestras plataformas y las buenas prácticas recomendadas. [11]
• Structured data on Commons will no longer ask whether you want to leave the page without saving. This will prevent the “information you’ve entered may not be saved” popups from appearing when no information have been entered. It will also make file pages on Commons load faster in certain cases. However, the popups will be hidden even if information has indeed been entered. If you accidentally close the page before saving the structured data you entered, that data will be lost. [12]

Cambios futuros

• Todas las wikis estarán en modo solo lectura por algunos minutos el 20 de marzo. Está previsto que esto ocurra a las 14:00 UTC. Se publicará más información en las Noticias Técnicas y de manera individual en cada wiki durante las próximas semanas. [13][14]

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

MediaWiki message delivery 23:04 11 mar 2024 (UTC)

Selección 2024 del Consejo Directivo de la Fundación Wikimedia

Pueden leer este mensaje traducido a otros idiomas en Meta-Wiki.

Más idiomas • Por favor, ayuda a traducir a tu idioma

Estimados todos y todas,

Este año, el periodo de 4 (cuatro) integrantes del Consejo Directivo seleccionados por la Comunidad y Organizaciones Afiliadas llegará a su fin [1]. El Consejo invita a todo el movimiento a participar en el proceso de selección de este año y a votar para seleccionar a quienes ocuparán dichos puestos.

El Comité de Elecciones supervisará este proceso con apoyo de personal de la Fundación [2]. El Comité de Gobernanza del Consejo creó un Grupo de Trabajo de Elecciones del Consejo a partir de aquellos integrantes que no pueden ser candidatos o candidatas en el proceso de selección 2024 de integrantes comunitarios o afiliados. Este grupo está compuesto por Dariusz Jemielniak, Nataliia Tymkiv, Esra'a Al Shafei, Kathy Collins, y Shani Evenstein Sigalov [3]. Este grupo tiene la tarea de supervisar al Consejoo para el proceso 2024 de elección de integrantes comunitarios de la Mesa, así como informar al Consejo Directivo de su proceso. Pueden encontrar más detalles acerca de los roles del Comité de Elecciones, el Consejo Directivo, y el personal aquí [4].

Aquí están las fechas planificadas:

• Mayo 2024: Convocatoria para candidatos/candidatas y solicitud de preguntas.
• Junio 2024: Las organizaciones Afiliadas votarán para reducir la lista a 12 candidatos o candidatas (este proceso no ocurrirá si se nominan 15 o menos candidatos) [5]
• Junio-Agosto 2024: Periodo de campaña
• Final de agosto / inicio de septiembre 2024: Periodo de votación de la comunidad por dos semanas
• Octubre-noviembre 2024: Revisión de trasfondo de candidatos/candidatas seleccionadas
• Reunión de la Mesa Directiva en diciembre 2024: Se instauran a los nuevos integrantes del Consejo Directivo

Pueden aprender más acerca del proceso de selección 2024—incluyendo un cronograma detallado, proceso de nominación de candidatos, reglas de campaña y criterios de elegibilidad de votantes—en esta página de Meta-wiki, para hacer sus planes de acuerdo a los detalles.

Voluntariado de elecciones

Otra forma de involucrarse con el proceso 2024 de selección es ser Voluntario o Voluntaria de Elecciones. El Voluntariado de Elecciones será un puente entre el Comité de Elecciones y su comunidad respectiva. El voluntariado ayudará a asegurar que su comunidad sea representada y los animará para votar. Pueden conocer más sobre este programa y cómo unirse en esta página en Meta-wiki.

Saludos cordiales,

Dariusz Jemielniak (Integrante del Comité de Gobernanza, Grupo de Trabajo de Elecciones del Consejo)

[1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_elections/2021/Results#Elected

[2] https://foundation.wikimedia.org/wiki/Committee:Elections_Committee_Charter

[3] https://foundation.wikimedia.org/wiki/Minutes:2023-08-15#Governance_Committee

[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_committee/Roles

[5] Aunque el número ideal es de 12 candidatos/candidatas para cuatro posiciones vacantes, el proceso de reducción de la lista se llevará a cabo si hay más de 15 candidatos porque los 1-3 candidatos que serían removidos pueden sentirse alienados y sería demasiado trabajo para las organizaciones afiliadas llevar a cabo todo el proceso solamente para eliminar de 1-3 candidatos o candidatas de la lista.

MPossoupe_(WMF)19:57 12 mar 2024 (UTC)

Tu wiki estará en solo lectura pronto

Lee este mensaje en otro idioma • Por favor, ayuda a traducir a tu idioma

La Fundación Wikimedia moverá el tráfico a otro de sus centros de datos (CPD). Esto permite asegurar que, incluso después de un desastre, Wikipedia y las demás wikis de Wikimedia puedan seguir funcionando.

Todo el tráfico cambiará al nuevo centro de datos el 20 marzo. La prueba comenzará a las 14:00 UTC.

Lamentablemente, debido a algunas limitaciones en MediaWiki, no será posible editar mientras se realiza el cambio. Nos disculpamos por esta interrupción, y estamos trabajando para minimizarla en el futuro.

Se podrán leer, pero no editar, todas las wikis durante un corto período de tiempo.

• No se podrá editar durante un máximo de una hora el miércoles 20 marzo 2024.
• Si tratas de editar o guardar durante ese período, verás un mensaje de error. Esperamos que ninguna edición se pierda durante esos minutos, pero no podemos garantizarlo. Si ves el mensaje de error, por favor aguarda hasta que todo vuelva a la normalidad. Después podrás guardar tus ediciones. Sin embargo, recomendamos que primero realices una copia de tus cambios, solo por si acaso.

Otros efectos:

• Los trabajos en segundo plano funcionarán algo más lento y algunos podrían ser descartados. Los enlaces en rojo no serán actualizados de forma tan rápida como ocurre normalmente. Si creaste un artículo que ya está enlazado en otra parte, ese enlace seguirá estando en rojo un poco más de tiempo de lo habitual. Varios scripts de larga duración serán detenidos.
• Esperamos que las actualizaciones de código ocurran normalmente como una semana normal. Sin embargo, en algunos casos podría congelarse el despliegue del código, en caso de que fuera necesario.
• GitLab no estará disponible por cerca de 90 minutos.

Este proyecto podrá ser aplazado de ser necesario. Puedes consultar la agenda en wikitech.wikimedia.org. Cualquier cambio será anunciado en la agenda. Habrá más notificaciones al respecto. Se mostrará un banner de aviso en todas las wikis 30 minutos antes de que ocurra esta operación. Comparte por favor esta información con tu comunidad.

Trizek (WMF), 00:00 15 mar 2024 (UTC)

antídoto

¿Qué pasó el 2020 que hizo que Peter Bowman tuviera que borrar esta entrada? ¿Alguien hizo copia y pega del diccionario de la RAE sin saber que era ilegal? Rodrigo5260 (discusión) 19:02 15 mar 2024 (UTC)

@Rodrigo5260 No tenemos tiempo para andar discutiendo sobre estas cosas. Todo el tiempo se cometen este tipo de faltas en las ediciones, sabés la cantidad de páginas que fueron borradas por esto? Podrías crear la entrada vos mismo; si está bien hecha nadie la va a borrar. Saludos. Tmagc (discusión) 01:49 16 mar 2024 (UTC)

Armenio

el Pron-graf debería poder general una transliteración de este idioma porque su grafía es relativamente regular, como en Wikcionario el inglés. Rodrigo5260 (discusión) 19:05 15 mar 2024 (UTC)

@Rodrigo5260 Tengo otras cosas más importantes que atender por el momento como para andar viendo eso en el corto plazo. Si tenés tiempo, podrías revisar en.wikt y meter mano en Módulo:generar-pron/hy para agregar la parte que translitere. Saludos Tmagc (discusión) 01:47 16 mar 2024 (UTC)

Griego antiguo

Algo ha generado la categoría masiva y aún no creada Categoría:ES:Palabras de origen griego clásico cuando debería llamarse como la ya existente Categoría:ES:Palabras de origen griego antiguo. - 188.76.241.151 (discusión) 10:10 15 mar 2024 (UTC)

Así es. Para evitar todos estos problemas nuevos que surgieron tras haber cambiado el sistema de idiomas y las implementaciones de las plantillas, justamente más arriba propuse renombrar todas estas catagorías como “Categoría:XX:Palabras provenientes del (Idioma)”, ya que esa denominación queda mejor, es más flexible y evita tener una capa extra que normalice los nombres de los idiomas. Lo mismo pasaba con el latín. Tmagc (discusión) 12:35 15 mar 2024 (UTC)

A lo que me refiero es que grc ha de llamarse "griego antiguo" y no "griego clásico". En alguna parte se ha asignado al código grc la denominación "griego clásico". - 188.76.241.151 (discusión) 13:12 15 mar 2024 (UTC)

grc siempre fue “griego clásico” (perdón, me tengo que desdecir, no me había dado cuenta de que era griego antiguo), no veo cuál es el motivo para preferir la denominación “griego antiguo” cuando “griego clásico” justamente lo identifica con el período clásico, es decir esta nueva denominación sería mucho más precisa.Tmagc (discusión) 01:52 16 mar 2024 (UTC)

El motivo para no llamarlo griego clásico no es otro que el de que esa denominación es la que abarca el griego que se habló únicamente durante unos 200 o 250 años tras la época de los siete sabios. Es una denominación tremendamente restrictiva que, por poner un solo ejemplo, excluye a Homero. El arcipreste de Hita (arçipreste de Fita) o Cervantes (Cerbantes) son ya de hace más de dos siglos pero no se nos ocurre decir que no hablaban castellano. La denominación de griego antiguo abarca mucho más tiempo y variantes (griego clásico incluido) que la de griego clásico. - 188.76.241.151 (discusión) 03:10 17 mar 2024 (UTC)

De acuerdo. Tmagc (discusión) 03:25 17 mar 2024 (UTC)

Ni el Arcipreste de Hita ni Cervantes hablaban castellano moderno, el código para el castellano antiguo es osp y el castellano medio no tiene, creo. Saludos. Lin linao ¿dime? 18:33 18 mar 2024 (UTC)

Diccionarios en Proyecto Gutenberg

Creo que esto puede interesarle a alguien: [https://www.gutenberg.org/ebooks/search/?query=Diccionario&submit_search=Search en Proyecto Gutenberg existen 4 diccionarios al español:

• Inglés-Español-Tagalog
• Español-Alemán
• Bagobo-Español
• Bisaya (Cebuano)-Español

Además de al menos 140 diccionarios en inglés. Todo en dominio público. Si a alguien le interesa estoy dispuesto a cooperar para importar, clasificar, lo que se les ocurra, con ayuda de herramientas automáticas. Ignacio ( — Δ — ) 05:41 17 mar 2024 (UTC)

Yo tenía pensadas cosas como estas pero dentro de un buen tiempo. Primero quiero terminar de migrar lo que queda y definir cómo va a ser la nueva estructura de las págians para que no sea un proceso caótico. Tmagc (discusión) 13:40 17 mar 2024 (UTC)

Noticias técnicas: 2024-12

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

Cambios recientes

• El aviso de "Los enlaces de idiomas están en la parte superior de la página" que aparece en la piel Vector 2022 fue eliminado debido a que los usuarios ya conocen acerca de la nueva ubicación de esta opción. [15]
• La información de IP muestra datos desde Spur, una base de datos de IP. Anteriormente mostraba datos solamente de MaxMind. Desde ahora, la información de IP será más útil para los patrulleros. [16]
• Los servicios de Toolforge Grid Engine fueron terminados tras un proceso final de migración desde el Grid Engine a Kubernetes. [17][18][19]
• La comunidades pueden personalizar los motivos de restauraciones al crear MediaWiki:Undelete-comment-dropdown. [20]

Problemas

• RevisionSlider es una interfaz que permite navegar en forma interactiva por el historial de una página. Los usuarios con idiomas de escritura de derecha a izquierda reportaron que RevisionSlder estaba reaccionando en forma incorrecta a los clics del mouse. Esto ya debería estar solucionado. [21]

Cambios durante esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 19 de marzo. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 20 de marzo y en todas las wikis a partir del 21 de marzo (calendario). [22][23]
• Todas las wikis están en modo de solo lectura por algunos minutos el 20 de marzo. Está planificado para las 14:00 UTC. [24][25]

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

MediaWiki message delivery 17:39 18 mar 2024 (UTC)

Categoría:IdiomaX-Español

Estoy viendo y queda un poco raro que todas las palabras del español aparezcan en Categoría:Español, pero que en lo demás idiomas sea Categoría:IdiomaX-Español, siendo que ya existe también Categoría:IdiomaX pero que está vacía. Si les parece, unifico todas las categorías a Categoría:IdiomaX. Hay otras categorías que parecen no tener sentido o no aportar información significativa, por ejemplo las que clasifican las palabras por prefijo. Habría que borrar las invocaciones a estas categorías, que ni siquiera están hechas por plantilla y después borrar las página propia de la categoría... Tmagc (discusión) 17:07 22 mar 2024 (UTC)

Creo que esto se hizo así para diferenciar las acepciones propias de cada idioma (p. ej. Categoría:Francés-Español) de sus traducciones (Categoría:Español-Francés). Pero, por otro lado, ahora no sabría decir por qué también hay páginas categorizadas dentro de Categoría:Francés, y creo que no pasa nada por alinear estas categorías con la del español como propones. Peter Bowman (discusión) 17:51 22 mar 2024 (UTC)

Plantillas "cita libro" y "referencia"

Me encuentro con que en la plantilla cita_libro aparece un mensaje diciendo que está obsoleta y que conviene usar la plantilla referencia en su lugar pero ambas plantillas son adecuadas para cosas distintas (la primera posibilita añadir más información y estructurarla con un entorno predeterminado mientras que la segunda es más "de andar por casa") de modo que no entiendo bien la razón del aviso. Empecé a buscar en el historial el momento en que se añadió la advertencia sin llegar a encontrarlo (falta de tiempo y mala conexión). Lo que está claro es que el aviso se añadió hace más de una década a la plantilla pero esta ha seguido siendo usada igualmente y sin aparente problema. ¿Realmente conviene una más que otra? 188.76.241.151 (discusión) 14:00 25 mar 2024 (UTC)

No. {{cita libro}} está obsoleta desde hace unos meses cuando decidí unificar todas las plantillas de referencias. LA única plantilla que vale es, por lo tanto, {{referencia}}. Y la primera mencionada no complementa nada ni agrega información que sea significativa y que no esté contemplada en la segunda. Todas las plantillas que tienen ese aviso tarde o temprano van a ser migradas a las versiones nuevas. Tmagc (discusión) 14:23 25 mar 2024 (UTC)

¿Entonces lo decidiste solo tú? ¿Razones? --188.76.241.151 (discusión) 14:48 25 mar 2024 (UTC)

Estimado, publiqué un hilo acá en diciembre del año pasado simplemente preguntando si querían unificar la plantilla de referencias. No hay una "razón" en sentido estricto, sólo se trata de un cambio de paradigma: para mí, cuanto menos plantillas haya, mejor será. Por eso di de baja las plantillas de idiomas, las de contexto, y no te sorprenda si más adelante me dan ganas de unificar todas las plantillas de flexión en una sola. Además, combina perfectamente con {{ejemplo}} ya que como estaba antes se asumía que lo único que se podía citar era un libro. Además, agregué campos nuevos, agregué la validación para los códigos y las fechas, y otras cosas más que no sé por qué nunca las agregaron antes. Hay algún problema? Tmagc (discusión) 16:03 25 mar 2024 (UTC)

Noticias técnicas: 2024-13

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

Cambios recientes

• Se realizó una actualización el 18 de marzo de 2024 sobre cómo varios proyectos cargan el sitio, el JavaScript del usuario y el CSS en la piel Vector 2022. Se proporciona una lista de verificación para que la sigan los administradores del sitio.

Cambios de esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 26 de marzo. Se instalará en todas las wikis que no son wikipedias y en algunas wikipedias el 27 de marzo y en todas las wikis a partir del 28 de marzo (calendario). [26][27]

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

MediaWiki message delivery 18:56 25 mar 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 ([28]), 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): [29]. 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. [30]

Problemas

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

Cambios esta semana

• Podrás usar wikienlaces en los títulos de los temas de Flow. [32]
• 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. [33]
• 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. [34]
• 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. [35]
• Podrás usar coloreado de sintaxis en el editor visual cuando escribas formulas matemáticas con LaTeX. [36]
• La apariencia del asistente de subidas cambiará ligeramente. [37]
• 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. [38]

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

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: [40]. 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. [41]
• 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. [42]

Cambios futuros

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

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 {{ejemplo}} 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)