Wikcionario:Café/2016 04

Revisión de Wikcionario:Estructura

No archivar hasta que se haya llegado a una solución

En la revisión de Wikcionario:Estructura, bajo Etimología explico que dicha sección es omitida en artículos de formas flexivas. pero luego más abajo intentando justificar la estructura especial que le damos a las formas flexivas, no encuentro argumento válido o favorable a la omisión de las etimologías de formas flexivas. la política de reducir al mínimo la información que les agregamos indicando a la base léxica es argumento suficiente para la mayoría de la información, pero no para las etimologías.
siempre se puede exponer la morfología, por ejemplo para la forma verbal amaban:

am-a-ba-n: am- (raíz), -a- (vocal temática), -ba- (morfema de tiempo y modo) y -n (morfema de persona y número).

incluso un análisis más simple seguiría siendo información específica al lema en cuestión y no de la base léxica:

De la raíz am- y la desinencia -aban.

o

De amar y el sufijo flexivo -aban.

es decir, si un usuario desea tomarse el tiempo (y va a requerir de mucho tiempo si quiere agregar todas las morfologías, je) no se lo podemos prohibir.
en duda queda donde poner dicha información. que el título "Etimología" sea optativo como con las locuciones, teniendo en cuenta que quebraría aún más con la uniformidad de la estructura de las formas flexivas, y se vería más o menos así:

=== Etimología ===
De la raíz am-, la vocal temática -a-, el morfema de tiempo y modo -ba- y el morfema de persona y número -n (am-a-ba-n).
=== Forma verbal ===
1 Tercera persona del blabla.

o indicar que se agregue la morfología bajo el título "Forma flexiva", subrayando el trato diferenciado, y se vería así:

=== Forma flexiva ===
De la raíz am-, la vocal temática -a-, el morfema de tiempo y modo -ba- y el morfema de persona y número -n (am-a-ba-n).
=== Forma verbal ===
1 Tercera persona del blabla.

a alguien se le ocurre una mejor opción? espero unos días luego ponemos todas las opciones a voto, así puedo terminar con la "Estructura especial", y Peter puede afilar los últimos parámetros de su bot... --Ninud (discusión) 13:59 17 ene 2016 (UTC)

La omisión (aunque no estricta) de la etimología en las formas flexivas se aprobó como política en esta discusión: WN:Café/2012 12#Etimología de formas no canónicas. Mi bot actualmente borra las plantillas {{etimología}} y {{etimología2}} vacías, las {{etimología}} con el primer parámetro tomando el valor femenino, plural o sufijo, y las {{etimología2}} si se ajustan a un formato determinado (Véase lema_base, De xx y el sufijo flexivo -s, etc.). Si un usuario desea añadir etimologías de este tipo, creo que sería conveniente reabrir aquel hilo: primero, para tratar de preservar el formato y contenido de las mismas, pues estamos ante un grupo de entradas altamente homogéneo (sería raro informar de la desinencia en una forma verbal y de un sufijo flexivo en otra); segundo, porque será difícil que llegue a editar un porcentaje significante de todo el conjunto de formas flexivas, y si el resultado es tener unos miles de entradas con etimología de formato variable (ver punto anterior) y otros cientos de miles sin etimología, mejor hablarlo primero y contratar a un bot después.

Volviendo a la propuesta (la política admite casos particulares, como las formas irregulares mencionadas en aquella discusión), tal vez sea más coherente usar el título Forma flexiva, pensando sobre todo en las entradas donde coincidiría un lema base con una de estas formas (reaprovecharíamos este título para indicar los morfemas flexivos debajo del mismo). Adicionalmente, surgiría la oportunidad de crear una plantilla especializada (punto 3). Si se diese el caso de que dos tipos de formas (p. ej. adjetiva y verbal) coinciden en una misma entrada, puede que la solución más simple sea concentrar la etimología de ambas en el mismo sitio. Un saludo, Peter Bowman (discusión) 19:46 17 ene 2016 (UTC)

Por cierto, gracias por revisar WN:ES :). Lo estuve postergando demasiado tiempo, prestándole más atención al código y su mantenimiento. Peter Bowman (discusión) 19:51 17 ene 2016 (UTC)

pido perdón por generarnos más trabajo. y sí, la idea es de definir bien un formato ahora, así más tarde no se nos cae el techo encima.

es un dilema el de la baja participación en wikcionario. aquella decisión (no hubo voto oficial, al menos no lo encontré) la tomaron Edgefield, Alakrano y Pacostein (más las opiniones de 2 usuarios no registrados). aunque hayan tratado de abordar el tema desde distintos ángulos (y no me cabe duda de la sinceridad y seriedad con que lo hicieron), difícilmente se puede decir que tan pocas voces sean legítimamente representativas de un punto de vista neutral, por otro lado omitir información definitivamente no lo es, de hecho todo lo contrario, por más de que hubiese consenso absoluto el punto de vista es subjetivo (si el punto de vista neutral es parte de la constitución de wikimedia, aquella decisión fue anticonstitucional).

en la guía de como estructurar las formas flexivas iba a introducir con algo así: "Incluimos solo la información pertinente al lema, las pronunciaciones, a veces alguna variante y las acepciones, el resto de la información se puede encontrar en su base léxica."

¿y la etimología? a no ser que alteremos las tablas de conjugación incluyéndoles el análisis morfológico (ver Wikcionario:Referencia/LA/Morfología/Verbos#Formas_personales_con_tema_del_presente).

¿cómo justifico esta omisión? "Incluimos solo la información pertinente al lema, las pronunciaciones, a veces alguna variante y las acepciones, el resto de la información se puede encontrar en su base léxica, excepto las etimologías que omitimos porque nos da mucho trabajo..." <sátira> le podría agregar un smiley haciendo pucherito: ;( </sátira>

la categorización según el sufijo flexivo, en parte, ya se puede encontrar bajo Categoría:ES:Rimas, aunque indirectamente, desde la fonética (je... ¿y por qué admitimos las rimas pero no las etimologías? por cierto, algo que ya mencioné: las rimas se pueden agregar sin más a la plantilla pron-graf, que un parámetro más o menos no va hacer la diferencia ;P). en conjuntos mayores también bajo formas, por ejemplo Categoría:ES:Formas sustantivas en plural (-s, -es, etc.). tampoco veo daño en crear todas las categorías de palabras formadas por sufijos flexivos.

pero volviendo a la estructura: yo pensé lo mismo sobre "Forma flexiva". podríamos globalizar más el trato indiscriminado de las formas flexivas y encabezar como estándar todas las formas con ese título (por cierto, era lo que entendía con aquel voto, y no sé por qué lo especifiqué tanto... luego me acobardé de retractarme ;P), si de todas maneras tarde o temprano se irán agregando las etimologías...

sobre el bot: agregar etimologías simples (base léxica + sufijo flexivo) a partir de las plantillas de conjugación sería fácil, que ya está toda la información allí.

más complicado sería el análisis completo (raíz + diversos morfemas).

sobre la coincidencia de sufijos flexivos ya tenemos la plantilla {{catafijo}} que vengo usando para subcategorizar en latín, por ejemplo -ō₁ (sust.), -ō₂ (adv.) y -ō₃ (verb.) en Categoría:LA:Palabras con el sufijo -o. pero claro, sería mucho mejor poder categorizar a partir de una plantilla maestra, tal vez {{morfología}}? y ahora veo que ya existe, aunque de poco uso, y se estuvo incluyendo bajo "Información adicional" (debería ir bajo etimología, incluso cuando se combine con {{etimología}}). podríamos modificar aquella para que se encargue de las diversas categorizaciones.

resumen:

• no podemos exigir que cierta información sea excluida, pero en el caso de las etimologías de formas flexivas tampoco podemos obligar a incluirlas, que en la mayoría de los casos quedarían vacías durante mucho tiempo.
• consecuencia: etimología optativa para las formas flexivas.
• tarea:
  • votar sobre el formato
  • crear una plantilla (o arreglar la existente {{morfología}})

--Ninud (discusión) 13:52 18 ene 2016 (UTC)

Estructuras especiales dentro de estructuras especiales

dejando de lado los casos intratables, como edere y ederis, que siempre van a salirse del marco de la estructura que finalmente apliquemos, quería mencionar casos más comunes, también en español, como las formas verbales sale (de salir y salar), barro (de barrar y barrer), etc., que requerirían un cuidado más especial aún. siguiendo lo votado (y en votación aún) la estructuración más lógica (aunque tal vez no la más atractiva estéticamente) sería enumerando Formas flexivas como si fueran Etimologías, por ej. para barro:

=={{lengua|es}}==
===Etimología 1===
====Sustantivo masculino====
...
===Etimología 2===
====Sustantivo masculino====
...
===Forma flexiva 1===
Barrer + el sufijo flexivo -o2.

====Forma verbal====

;1: {{f.v|barrer|yo|pres|ind}}.

===Forma flexiva 2===
Barrar + el sufijo flexivo -o2.

====Forma verbal====

;1: {{f.v|barrar|yo|pres|ind}}.

alternativamente se podría enumerar las formas verbales colocando las morfologías bajo estas:

...
===Forma flexiva===

====Forma verbal 1====
Barrer + el sufijo flexivo -o2.

;1: {{f.v|barrer|yo|pres|ind}}.

====Forma verbal 2====
Barrar + el sufijo flexivo -o2.

;1: {{f.v|barrar|yo|pres|ind}}.

sin olvidarse que también en español tenemos entradas más complicadas aún, como barra, que además de partir de dos bases léxicas también se forman con varios sufijos flexivos (por cierto -a₂ habría que subdividir que son dos etimologías distintas). para estas formas la segunda alternativa sería más viable. tal vez se podría introducir con Morfología:, también se podría colocar bajo la acepción. que les parece?

nota sobre el análisis morfológico avanzado: siguiendo la política de redirigir hacia la entrada principal se me ocurre que no hay problemas si dejamos estos análisis avanzados para las respectivas entradas de los sufijos flexivos.
por ej., un análisis avanzado del sufijo flexivo -aban ( -a-ba-n: -a- (vocal temática), -ba- (morfema de tiempo y modo) y -n (morfema de persona y número)) solo figuraría una vez en wikcionario, dentro del artículo del sufijo flexivo -aban.
de este modo podemos mantener las entradas de formas flexivas reducidas sin omitir información. así es que al menos un alivio desde ese punto :)
--Ninud (discusión) 13:39 24 ene 2016 (UTC)

una alternativa mucho más simple que nos permitiría continuar con la estructura tal y cual estaba:

poniendo las morfologías bajo cada acepción con {{morfología}} (con algunas modificaciones), así tampoco hace falta repetir la base léxica y se puede poner raíz + sufijo flexivo.

viéndose así:

...
===Forma flexiva===
====Forma verbal====

;1: {{f.v|barrer|yo|pres|ind}}.
:* Morfología: barr-o, raíz barr- + sufijo flexivo -o2.

;2: {{f.v|barrar|yo|pres|ind}}.
:* Morfología: barr-o, raíz barr- + sufijo flexivo -o2.

--Ninud (discusión) 12:55 26 ene 2016 (UTC)

(corrijo indentación (:*)) Habrá que tener cuidado con las entradas del tipo -a si hubiera que modificar alguna etimología, cambiarla de sitio o hacer otro cambio considerable y ya tuviéramos miles de ocurrencias de este sufijo en la morfología de las formas flexivas (ver barra). Básicamente, sería algo similar a lo que trataba de advertír recientemente en tu página de discusión, incluso me plantearía proteger estas páginas de alguna manera (del mismo modo que se protegen las plantillas más usadas). Me pregunto cómo se aplicaría esto en un caso como la forma kości del sustantivo polaco kość (ver flexión), que corresponde a ocho casos gramaticales. Si no fuera posible establecer ocho etimologías (o las que sean) en la entrada -i, al final acabaría obviando el subíndice y pegando la misma información morfológica en las ocho acepciones. ¿No se vería un poco abultado y, obviamente, repetitivo? Un saludo, Peter Bowman (discusión) 21:36 28 ene 2016 (UTC)

para el español esto no debería presentar dificultades gracias a la sobreabundancia de información etimológica (incluso de la morfología del latín). deberíamos adelantarnos y crear todos los artículos de los sufijos flexivos y ya.

en el caso del sufijo flexivo -i dentro del polaco no sabría decirte, pero te puedo ofrecer una comparación de como sería en un caso en latín:

dentro del paradigma flexivo de la primera y segunda declinación el sufijo flexivo -ō (incompleto en wikcionario) denota en el clásico el dativo y ablativo singular masculino y neutro, estos se diferenciaban hasta mediados del siglo III a.C.: el dativo era -ōi, el ablativo -ōd (dativo -ō_x, ablativo -ō_y). por otro lado el plural del dativo y ablativo de todos los géneros en el clásico es -īs, pero aquí masculino y neutro comparten la misma etimología -ois (<*-ōis), mientras que el femenino era -ais (<*-āis) (dativo y ablativo plural masculino y neutro -īs_x, dativo y ablativo plural femenino -īs_y)

volviendo al polaco: habrá que ver los estudios etimológicos que haya al respecto. si las ocho desinencias difiriesen en la etimología, entonces lógicamente habría que crear num=<1 a 8>, si son irreconstruibles o se supone que en el protoeslavo ya eran iguales quedaría en una etimología.

(y sí, siempre pueden aparecer estudios y propuestas nuevas que nos obligarán a cambiar o incluir información)

--Ninud (discusión) 11:57 29 ene 2016 (UTC)

A mi la verdad se me hace mucho lío, no lo tengo nada claro (ver Wikcionario:Café#Sobre las formas flexivas) por eso no sabría que responder--Esceptic0 (discusión) 04:49 19 mar 2016 (UTC)

bueno, en realidad no es tan complicado. el análisis de varias de las posibles alternativas, y especialmente el análisis de casos excepcionales generados por una u otra alternativa, ya está hecho (leer y estudiar eso es lo complicado ;P). la única alternativa que no nos va a generar excepciones (que haya encontrado) es la que ensayé en barra (Forma flexiva), con el mismo formato de {{sinónimo}}, {{antónimo}}, etc.:
Morfología: base léxica + sufijo flexivo[enlazando a este]
ej. amemos:

• Morfología: am-emos₂

(donde num=2 es subjuntivo presente de la 1ra conj.; mientras num=1 sería indicativo presente de la 2da conj., ej. tememos)
luego en las entradas de los sufijos flexivos se puede dar toda la información (incluyendo la extenuante en torno a la segmentación).
simple y elegante. sobre todo, no nos obliga a hacer ningún cambio en la estructura.

ahora el caso de los sustantivos agentes femeninos derivados de masculinos es un tema más delicado. pero sí deberíamos darles a todos el mismo formato (a mi personalmente me convence más como está en vendedora, una vez adaptado a la nueva estructura, claro) --Ninud (discusión) 12:25 19 mar 2016 (UTC)

Voto: Etimología de formas flexivas

I. ¿Con o sin título? ¿Bajo que título, "Forma flexiva" o "Etimología"? (o alguien tiene un título mejor?)

1. Forma flexiva

A favor, como comenta Peter, ya lo aplicamos en casos que se combinan formas base con formas flexivas --Ninud (discusión) 13:52 18 ene 2016 (UTC) anulo mi voto en favor de la forma más simple propuesta más abajo (dejando la estructura como estaba, agregando morfologías individuales bajo cada acepción) --Ninud (discusión) 12:59 26 ene 2016 (UTC)

1. A favor, Peter Bowman (discusión) 01:59 24 ene 2016 (UTC)

2. Etimología

3. Sin título, bajo la acepción con la plantilla {{morfología}} (modificada, el análisis más simple, sin descripciones y redirigiendo hacia el artículo de la forma flexiva, se vería como en barra).

1. A favor, esta propuesta no nos genera casos especiales ni excepciones, no nos llena las páginas de subtítulos, nos permite dejar la estructura tal y cual está, y no se ve mal estéticamente. --Ninud (discusión) 12:43 27 ene 2016 (UTC)

<comentario pasivo-agresivo> cierro la votación por falta de interés, quedando así abierto el lugar donde colocar las etimologías (morfologías en verdad) de las formas flexivas </comentario pasivo-agresivo> --Ninud (discusión) 10:42 9 abr 2016 (UTC)

Tech News: 2016-14

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

Cambios recientes

• Puedes filtrar Especial:Registro de forma más detallada. [1]
• Las wikis de Wikimedia ahora tienen una nueva forma de contar visitantes. [2]

Cambios esta semana

• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 5 de abril, en todas las wikis que no son wikipedias y en algunas wikipedias el 6 de abril y en las wikipedias restantes el 7 de abril (calendario).

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

22:13 4 abr 2016 (UTC)

Tenemos editor visual !!!

=D

Ahora lo que hay que hacer para que sea funcional es completar las Wikipedia:TemplateData. Ánimo, y si fuiste vos Peter Bowman Bien ahí gracias jej--Esceptic0 (discusión) 16:20 7 abr 2016 (UTC)

No fui yo, y me parece que ha sido un error... Según puedo leer en phab, la intención era introducir una función en pruebas para que el que quiera pueda activarla en sus preferencias (opt-in); sin embargo, la tengo desactivada y me deja alternar entre editores, lo mismo pasa cuando trato de editar desde una IP. Sinceramente, espero que lo quiten cuanto antes. Un saludo, Peter Bowman (discusión) 19:45 7 abr 2016 (UTC)

a mi personalmente no me molesta que permita alternar entre editores.

pero, como primer test, quise agregar una pronunciación y el editor no da acceso a escrituras (al menos no las encontré). más allá de eso parece ser útil.

--Ninud (discusión) 10:34 8 abr 2016 (UTC)

Permite alternar entre teclados, cuando haces clic en la caja de texto aparece uno abajo a la derecha y se puede elegir el idioma que se quiera. El "como utilizar" deriva a esta página

Intenté crear una entrada y habría que ajustar varias cosas del formato, pienso que usarlo va a aumentar la productividad ya que al no tener que usar wikicódigo hay menos errores y todo es mas simple, rápido.

Tuve problemas al intentar agregar mas de una acepción, no pude insertar una segunda para que quede bien en formato, también al alternar se me rompió el subtítulo en la plantilla de sección--Esceptic0 (discusión) 11:22 8 abr 2016 (UTC)

Creo que habría que cambiar todos los preload para que sea útil el editor mas que destructivo. Se podrían descomentar muchas partes y solo habría que ir eliminando como hacemos hasta ahora con el wikicódigo. Por ejemplo algo así: Usuario:Esceptic0/taller/editorvisual. También se pueden crear nuevas formas de introducir plantillas ya que ahora contamos con un buscador de las mismas, por ejemplo para los campos semánticos si creamos redirecciones con CM delante de cada una, tendríamos toda la lista disponible sin salir de la entrada que estamos editando--Esceptic0 (discusión) 19:24 8 abr 2016 (UTC)

al editar dentro de la plantilla pron-graf (o cualquier otra plantilla) me da 4 opciones: "añadir una plantilla", "añadir contenido", "añadir más información" y "eliminar".

el acceso a todas las demás opciones (como símbolos especiales) quedan bloqueados.

y, en general, noto lo mismo que ya había notado cuando probé el editor visual por primera vez (creo que fue en wikipedia o wikcionario francés): no es tan intuitivo, de hecho para mi, conociendo el código, me resulta más intuitivo y más rápido el editor tradicional.

conclusión preliminar: mientras que el editor visual no afecte negativamente al editor tradicional será bienvenido. pero recordar, que como mencionó peter, no fuimos consultados antes de que se active.

--Ninud (discusión) 10:06 9 abr 2016 (UTC)

Cree una redirección de Pron-graf (con mayúscula) nose porque tomaba esa. No se si me explico bien te dejo una imagen de lo que nombraba donde te cambia los teclados [3]. Ahí cree el TemplateData de pron-graf por lo que ahora aparecen las opciones pero tengo algunos problemas con que algunas descripciones no aparecen y no quiero que aparezcan todas las opciones--Esceptic0 (discusión) 06:02 10 abr 2016 (UTC)

sí, entendí, y no me aparece esa opción. será que ocurre porque trabajo con linux? --Ninud (discusión) 09:24 10 abr 2016 (UTC)

Ninud: creo que has desactivado las herramientas de entrada. En el panel derecho, haz clic en el icono de la rueda dentada al lado de Idiomas, luego Entrada y Activar las herramientas de entrada.

Esceptic0: en el tema de las redirecciones hay que andar con pies de plomo, un abuso de ellas es siempre un problema (no solo por lo que menciono en Plantilla discusión:trad-véase). ¿Para qué nos sirve esa redirección de pron-graf? ¿Podemos borrarla? Por lo que veo, el editor sí que me reconoce la plantilla correcta. ¿En qué consistía el error? Un saludo, Peter Bowman (discusión) 10:02 10 abr 2016 (UTC)

era por eso, gracias! :) --Ninud (discusión) 10:11 10 abr 2016 (UTC)

Borrala y fijate, al poner editar desde el editor visual decía "no existe la plantilla Pron-graf" con mayúscula, aunque la que esta en las entradas es con minúscula :/--Esceptic0 (discusión) 11:56 10 abr 2016 (UTC)

Cierto, funciona bien cuando intento añadir una plantilla nueva, pero si edito alguna de las que ya existían en la página, el cuadro de edición trata de cargar Pron-graf o aquella plantilla a la que esta redirija. Seguramente a los desarrolladores se les ha pasado por alto que los Wikcionarios distinguen entre mayúsculas y minúsculas en varios espacios de nombres. Mas tarde buscaré si alguien lo ha notificado en Phabricator, o si no crearé una tarea para que lo arreglen. Un saludo, Peter Bowman (discusión) 14:07 10 abr 2016 (UTC)

También tiene otro error creo, tal vez tu puedas visualizarlo mejor en el código, fijate que las descripciones de varios parámetros como "d", "e", "g" no aparecen aunque estén agregadas en el TemplateData.

┌─────────────────────────────┘
Entonces cambiamos todos los textos preload ?--Esceptic0 (discusión) 17:32 16 abr 2016 (UTC)

Idealmente, debería ser el Editor Visual o un complemento ejecutado por este el que guíe al editor en el proceso de edición y exponga todos estos elementos, es decir, que haya, por ejemplo, un menú en la interfaz que permita seleccionar y añadir marcas de uso, sinónimos, locuciones, adverbios según el tipo, etc. No me parecería una buena idea exponer un esqueleto como el que propones porque estoy convencido de que a más de un editor se le olvidará borrar los elementos que no necesite cuando vaya a guardar los cambios. Un saludo, Peter Bowman (discusión) 18:38 16 abr 2016 (UTC)

Si pero no tenemos ese tutor, los comentarios que aparecen con un {{!}} avisan que se debe borrar, o se puede poner explicitamente bien grande. Otro problema que acabo de notar [4]--Esceptic0 (discusión) 20:47 16 abr 2016 (UTC)

ahí por ejemplo agregué la plantilla comentario [5] ¿que les parece?--Esceptic0 (discusión) 16:11 18 abr 2016 (UTC)

En un principio en contra por lo dicho anteriormente: daría igual si lo ponemos en mayúsculas y negrita o en rojo y tamaño 100, no es bueno jugar así con la estructura de las entradas por una herramienta nueva aún con errores, y además optativa. Me gustaría poder ayudar con el bot como ya lo hace actualmente eliminando los comentarios sobrantes, las secciones vacías, etc., pero me está faltando tiempo para estas cosas (no digo que sea imposible que revisara también estos nuevos elementos). Apuesto por el tutor porque no se restringiría al escenario de crear una entrada nueva, sino que también abarcaría la edición de los lemas existentes. Hay una extensión llamada, me parece, GuidedTour, se le podría echar un vistazo. Un saludo, Peter Bowman (discusión) 17:26 18 abr 2016 (UTC)

Tech News: 2016-15

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

Cambios recientes

• El editor visual puede generar código wiki con opciones de imagen en tu idioma. Ejemplos de opciones de imagen son «miniaturadeimagen» e «izquierda». Puedes solicitar que se cambie las opciones en tu idioma en Phabricator. [6][7]
• Los Wikcionarios y los Wikisources ahora pueden utilizar el editor visual. Es una función opcional en prueba. Necesita más desarrollo para que trabaje mejor en estos proyectos. [8][9]
• ORES está utilizando nuevos modelos. Las herramientas que utilicen las predicciones de ORES podrían comportarse de manera extraña. ORES también tiene una nueva API. [10]
• El editor visual ahora tiene soporte para caracteres griegos clásicos. [11]

Problemas

• Un error ocurría con el editor visual cuando se utilizaba las flechas del teclado en las plantillas. Este error ya ha sido corregido. [12]

Cambios durante esta semana

• La nueva versión de MediaWiki estará activada en los wikis de prueba y en MediaWiki.org a partir del 12 de abril. Estará activada en algunas Wikipedias y los demás wikis a partir del 13 de abril. Estará activada en todos los wikis a partir del 14 de abril (calendario).
• El portal wikipedia.org tendrá varias correcciones y mejoras menores. La mayoría se realizará en el cuadro de búsqueda y en los resultados sugeridos que fueron añadidos en marzo. [13]

Reuniones

• Puedes asistir a la siguiente reunión del equipo del Editor Visual. Durante la reunión podrás indicar a los desarrolladores cuáles son los errores que consideras más importantes. La reunión se realizará el 12 de abril a las 19:00 UTC. Mira cómo asistir.
• Puedes asistir a la siguiente reunión del comité de Arquitectura. Los temas de esta semana son el mejoramiento de la transclusión de plantillas para Parsoid y plantillas balanceadas. La reunión se realizará el 13 de abril a las 21:00 UTC. Mira cómo asistir.

Cambios futuros

• Wikimedia tiene un nuevo centro de datos de respaldo en Dallas. Debido al trabajo planeado, podrás leer pero no editar los wikis durante un corto período de tiempo el 19 de abril y el 21 de abril. Este período comenzará a las 14:00 UTC y durará entre 15 y 30 minutos. [14]

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

20:44 11 abr 2016 (UTC)

No editing two times this week

La Fundación Wikimedia estará probando su nuevo centro de datos en Dallas. Esto garantizará que Wikipedia y los otros wikis de Wikimedia se mantengan en línea aun en caso de un desastre. Para garantizar que todo esté funcionando, el Departamento de Tecnología de Wikimedia debe realizar una prueba programada. Esta prueba mostrará si pueden cambiar sin problemas de un centro de datos a otro. Esto requiere que muchos equipos estén preparados para la prueba y que estén disponibles para arreglar cualquier problema inesperado.

Se cambiará todo el tráfico al nuevo centro de datos el martes 19 de abril.
El jueves 21 de abril volverán a colocarlo en el centro de datos primario.

Desafortunadamente, por causa de algunas limitaciones en MediaWiki, todas las ediciones serán detenidas durante esos dos cambios. Nos disculpamos por esa interrupción, y estamos trabajando para minimizarlo en el futuro.

Podrás leer aunque no editar todos los wikis por un corto período de tiempo.

• No podrás editar aproximadamente de 15 a 30 minutos el martes 19 de abril y el jueves 21 de abril, iniciando a las 14:00 UTC (16:00 CEST, 10:00 EDT, 07:00 PDT).
• Si tratas de editar o guardar durante ese período, verás un mensaje de error. Tenemos la esperanza que las ediciones no se perderán durante esos minutos, pero no podemos garantizarlo. Si ves el mensaje de error, espera 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 serán lentos y algunos podrían ser descartados. Los enlaces rojos no serán actualizados de forma rápida como ocurre normalmente. Si creaste un artículo que ya está enlazado en alguna otra parte, ese enlace seguirá estando en rojo más de lo usual. Varios scripts de larga duración deberán ser detenidos.
• Habrá un congelamiento en el código para la semana del 18 de abril. El despliegue de código que no sea esencial no será llevado a cabo.

Esta prueba fue originalmente planeada para llevarse a cabo el 22 de marzo. El 19 y 21 de abril son las nuevas fechas. Puedes consultar la agenda en wikitech.wikimedia.org. Se publicará cualquier cambio en esa agenda. Habrá más notificaciones sobre esto. Comparte esta información con tu comunidad. /Johan (WMF) (discusión) 22:07 17 abr 2016 (UTC)

Destacados de Wikimedia Marzo 2016

Estas son las noticias destacadas del blog de Wikimedia en Abril del 2016

• La nueva alquimia: Transformar el acoso en linea en artículos wikipédicos sobre mujeres científicas
• La nueva función de autocompletado con sugerencias te ayuda a encontrar lo que necesitas en los sitios de Wikimedia.
• Jimmy Wales le dice a «South by Southwest» que la comunidad es la clave del futuro de Wikipedia.
• En resumen

About · Subscribe · Distributed via MassMessage (wrong page? Correct it here), 18:39 18 abr 2016 (UTC)

Tech News: 2016-16

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

Cambios recientes

• Puedes filtrar Especial:Registro con mayor detalle. Puedes filtrar diferentes importaciones y usuarios nuevos. [15][16]
• Puedes utilizar Telnet para leer los wikis de Wikimedia. [17]
• Los wikis de MediaWiki pueden subir archivos más grandes. El nuevo límite es 4 GB. [18]

Cambios de esta semana

• Wikimedia tiene un nuevo centro de datos de respaldo en Dallas. Debido al trabajo planeado, podrás leer pero no editar los wikis durante un corto período de tiempo el 19 de abril y el 21 de abril. Este período comenzará a las 14:00 UTC y durará entre 15 y 30 minutos. [19]
• No hay una nueva versión de MediaWiki esta semana. Esto se deba a la prueba del centro de datos.

Reuniones

• Puedes asistir a la siguiente reunión del equipo del Editor Visual. Durante la reunión podrás indicar a los desarrolladores cuáles son los errores que consideras más importantes. La reunión se realizará en 19 de abril a las 19:00 UTC. Mira cómo asistir.
• Puedes asistir a la siguiente reunión del comité de Arquitectura. El tema de esta semana es nombres de espacio de sombra. La reunión se realizará el 20 de abril a las 21:30 UTC. Mira cómo asistir.

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

20:40 18 abr 2016 (UTC)

Fusión de vegetales a verduras

Hola. Modifiqué el campo semántico de las plantas marcadas como "vegetales" a "verduras". Hace falta que un administrador fusione el historial de {{vegetales}} en {{verduras}}. Gracias. Lin linao ¿dime? 14:00 12 abr 2016 (UTC)

me parece apropiado.

y ya que estoy, comento lo que ya había mencionado a peter sobre como presentamos y usamos los campos semánticos (hiperónimos glorificados en verdad) y otros etiquetajes.

• por un lado, los campos semánticos en negrita se llevan un protagonismo desproporcionado, quedando básicamente como títulos (por ese motivo los dejé de usar en las entradas en latín, es decir, doy la información pero sin las plantillas, ver disparilis, segunda definición).
• y en el otro extremo igualmente desproporcionado se tiran otras etiquetas, como el ámbito, el ámbito temporal (arcaico, tardío, etc.), información gramática y otra información sobre el uso.

Compárese la solución de los muchachos de wikt.en: en:Template:label

• y por último: hay algunas plantillas de uso que fueron ligadas que no son exactamente lo mismo y generan confusión, por ej. {{culto}} y {{académico}}, {{literario}} y {{poético}}; y dentro de los campos semánticos lo mismo, {{lingüística}} y {{gramática}}, etc.

--Ninud (discusión) 11:58 13 abr 2016 (UTC)

Buena idea lo de la cursiva. También interesante lo del Wikcionario en inglés. Saludos. Lin linao ¿dime? 15:49 13 abr 2016 (UTC)

No creo que quede mal en cursiva en vez de negrita pero no usando las plantillas no se categorizarían las entradas y ese es el objetivo de estas.

Además no son hiperónimos o en principio creo que son el ámbito en el cual se usa tal palabra, o se usa con más frecuencia. Luego se fueron agregando mas y se desvirtuó el propósito. No tengo ningua solución realmente--Esceptic0 (discusión) 19:48 15 abr 2016 (UTC)

si lo que se desea es retener las categorizaciones (que no es lo que critico acá) la solución más simple sería de quitarles el punto final a las plantillas de campos semánticos y colocarlas fuera de los enumeradores, por ejemplo:

;1: {{vegetales}}: acepción.

resultando en:

1

Vegetales: acepción.

en este momento por el punto final resultaría en:

1

Vegetales.: acepción.

Peter Bowman: daría mucho trabajo incluir un "reconocedor"? que si detecta que las plantillas se encuentran dentro de un enumerador ; x : retengan el punto, de otro modo que lo omitan? (como hiciste con la plantilla de etimología con respecto a las estructuras nueva y vieja)

PD: otro problema es la mayúscula, que algunas acepciones irían dentro de más de un campo semántico (para que no resulte en: Vegetales, Verduras:)

finalmente habría que estudiar la utilidad de algunas de las categorías de uso (por ejemplo Categoría:ES:Términos en sentido figurado), como ya en su momento eliminamos la categorización dentro de {{pron-graf}} de variantes, grafías alternativas, etc.
--Ninud (discusión) 09:13 16 abr 2016 (UTC)

Hola, Ninud. No, salvo que me olvide de algún caso especial, condicionar la presencia de ese punto a su ubicación dentro o fuera de un elemento de este tipo sería bastante simple. Ya que estamos, me pregunto si ese punto era realmente necesario ya que no cierra una oración completa (ver [20], si bien no son exactamente viñetas lo que tenemos aquí). Tampoco creo que sea difícil programar el bot para hacer este cambio, pero adicionalmente habría que buscar una forma de convertir la palabra que le sigue a minúscula inicial. O eso, o seguir con el esquema del punto con algo más cercano a lo que encontramos en el DRAE (ver "sumatorio"):

• Vegetales: acepción.
• Vegetales. Acepción.

Respecto a la mayúscula inicial de los sucesivos campos semánticos (en tu ejemplo, Verduras), probablemente se pueda ajustar esto automáticamente desde el código de la plantilla (no lo he mirado a fondo, pero si en la implementación actual no es realizable, seguro que con un módulo de Lua se podría hacer). Un saludo, Peter Bowman (discusión) 09:44 16 abr 2016 (UTC)

je, sí, el DRAE aún está aferrado al formato minimalista de un diccionario de papel. pero su sistema funciona bastante bien.

para evitar las mayúsculas también podríamos hacer como wikt.en, y colocar los campos semánticos dentro de un paréntesis con las categorías de uso (coloquial, etc.), así como información gramática (contable, incontable, transitivo, intransitivo, etc.) todo en minúscula, véase sleep. --Ninud (discusión) 10:29 16 abr 2016 (UTC)

La negrita creo que viene por el css, simplemente se cambia y listo. Si las ponemos entre paréntesis antes de la acepción ¿subimos la misma al lado del número? ¿la desindentamos?--Esceptic0 (discusión) 16:52 16 abr 2016 (UTC)

Actualmente, las acepciones se estructuran así:

<dl>
  <dt>1 Verduras, Matemáticas, Geografía</dt>
  <dd>Definición.</dd>
</dl>

Los elementos <dl> se denominan también listas de definiciones, vemos que la estructura sigue una secuencia lógica de situar el número de la acepción y las marcas de campo semántico en un elemento de cabecera (<dt>) y el cuerpo de la definición en uno o varios apartado subordinados <dd> (más o menos como situaríamos los elementos en una wikitabla: primero el título de una columna, resaltado en negrita, y abajo las filas que contienen los datos). Llevar las definiciones a la cabecera arruinaría en cierto modo la semántica de esta estructura (¿para qué usar listas de definiciones entonces?), podría complicar la ubicación de los elementos subordinados (¿qué hacer con los sinónimos, marcas de uso, etc.?) y, ante todo, haría engorroso el uso del signo de doble punto (:), que el motor de MW interpreta como uno de los componentes de la lista de definición, precisamente. Un saludo, Peter Bowman (discusión) 18:27 16 abr 2016 (UTC)

Yo la verdad no tengo mucha idea y como es un cambio importante creo que deberíamos hacer una votación. Podríamos dejar entonces el <dt> vacío o simplemente sin negrita y listo. O podríamos ir al punto crítico como dice Ninud y cuestionar la utilidad toda de los campos semánticos y considearar abandonarlos o ubicarlos en por ejemplo {{ámbito}}. Deberíamos tener una justificación explcícita del porqué usamos tales cosas, si alguien tiene alguna me vendría bien. --Esceptic0 (discusión) 13:31 21 abr 2016 (UTC)

Pie de foto

Hola a todos. A partir de esta conversación con Cyrax se me presentó la duda de si en algún momento se ha discutido o definido alguna convención sobre los pie de foto de las entradas de Wikcionario. La conversación surgió a partir de esta edición mía, basada en que el uso común que he visto de ellos es poner entre corchetes rectos el número de la acepción a la que hacen referencia. Un ejemplo sería la entrada «rueda». Me parece que si no se ha escrito nada al respecto, deberíamos crear alguna convención, por ejemplo, en Wikcionario:Estructura o en Wikcionario:Cómo añadir imágenes. Un saludo, --Ivanics (Res publica non dominetur) 22:49 18 abr 2016 (UTC)

Si es cierto haría falta definirlo, también está Wikcionario:Política de uso de imágenes que tampoco dice nada. Yo simplemente copié lo que hacían los demás que era eso, poner entre corchetes y cuando se necesita especificar el lema este va en cursiva, pero también lo he visto entre paréntesis u otras variantes. Tampoco dice en ningún lado pero el mejor lugar para ubicar las imágenes es sobre el título de la categoría gramtical (sustantivo, adjetivo, etc.). Lo ideal sería que se puedan enlazar individualmente las definiciones pero bueno es lo que hay por ahora. Con alguna plantilla incluso se puede poner sobre la imagen, véase gavetero--Esceptic0 (discusión) 09:24 19 abr 2016 (UTC)

Me gusta mucho lo que hiciste en esa entrada y sobre todo la posibilidad de hacer un Diccionario visual. Habría que probar si esa plantilla se lleva bien con los videos, que también son muy útiles para ilustrar muchas entradas, por ejemplo cañonazo. Pero un cambio que me parece necesario es que esas plantillas se pongan una debajo de la otra en lugar de lado a lado, porque si hay muchas terminarían desplazando el texto (lo que dañaría la maquetación, pienso que sobre todo en la versión para móviles de Wikcionario). --Ivanics (Res publica non dominetur) 01:05 20 abr 2016 (UTC)

modifiqué {{dicpic}} para que no forme conjeturas en una línea, → gavetero

sí, creo que no tenemos ningún reglamento oficial, aunque parece que siempre se usó el número entre corchetes, lo mismo en las traducciones (y en las locuciones, aunque no las españolas, que el DRAE no ofrece dicha información, ni ningún otro diccionario español, a diferencia de diccionarios en otros idiomas)

--Ninud (discusión) 09:30 20 abr 2016 (UTC)

En realidad las había puesto una al lado de la otra a propósito, era un experimento, pero bueno tampoco me convence mucho esa forma desde la llegada del visor de fotos porque lo inhabilita. Voy a avanzar un poco con eso del diccionario visual aunque creo que la prioridad son las plantillas preloads. Con respecto a cañonazo yo particularmente hubiera puesto [1-2] en vez de [1],[2]. Otra cosa a tener en cuenta es que cuando se usa el lema se debe añadir un subíndice explicando que acepción se está refiriendo y no haría falta tal vez el [1] como acabo de hacer por ejemplo en munición --Esceptic0 (discusión) 10:49 20 abr 2016 (UTC)

los subíndices están reservados para las homografías (llanta₁, llanta₂). para entreconectar acepciones bajo la misma etimología (que no se recomienda) también se debería recurrir al número de la acepción entre corchetes.

es un poco el problema de copiar el formato del DRAE que no prsenta las definiciones de forma analítica (por ej. subseccionándolas en a) b) c) etc., como hacen diccionarios del mismo calibre en otras lenguas).

PD: no solo el DRAE, este es un problema general de la lexicografía española.

--Ninud (discusión) 11:59 20 abr 2016 (UTC)

Es cierto me confundí con los subíndices dentro de la misma etimología para señalar otra acepción, ¿ahí si sería correcto no?--Esceptic0 (discusión) 12:10 20 abr 2016 (UTC)

┌─────────────────────────────┘
no lo recomiendo, yo diría de limitarlas para indicar etimologías. más que nada para evitar confusiones, imaginate usarlas en sero (se podría deducir, pero no sin dificultad). --Ninud (discusión) 12:38 20 abr 2016 (UTC)
en encajar un ejemplo de como resolverlo prescindiendo completamente de subíndices, subseccionando directamente, como hacen los mejores diccionarios en otras lenguas --Ninud (discusión) 12:51 20 abr 2016 (UTC)

En Miami hice muy mal no? como debería hacer? especialmente en la definición 11--Esceptic0 (discusión) 14:52 20 abr 2016 (UTC)

Hola. Me entusiasma mucho que hayas iniciado el Diccionario visual, porque creo que ese es uno de los campos en los que Wikcionario más útil puede serle a mucha gente, en especial a los que quieran usarlo como ayuda para aprender el español. Sobre la entrada que mencionas, mi aporte es que creo que las acepciones 9 a la 11 deberían de estar en miami, debido a lo de que «los nombres de tribus o pueblos y de lenguas, así como los gentilicios» no se escriben con mayúsculas. --Ivanics (Res publica non dominetur) 21:05 20 abr 2016 (UTC)

es verdad, ahí cree miami.

y no es que este mal. especialmente en este caso, con números tan altos, no había problemas. el problema es que si lo regularizamos van a aparecer casos donde se cruzan subíndices de etimologías y de acepciones...

y podemos prescindir de subíndices u otras indicaciones entre acepciones. ver miami, el contexto da toda la información necesaria. en casos extremos, donde hay más acepciones, también se puede dar información entre paréntesis: miami (lengua), miami (tribu), etc.

saludos :) --Ninud (discusión) 10:21 21 abr 2016 (UTC)

Plantillas de fuentes y autorizaciones

como se puede ver, dentro de dicha categoría contamos con un número elevado de plantillas. de estas, por no tener un sistema denominativo, pocas se descifran.
aunque más que un remedio es un paliativo, lo mínimo que se puede hacer es ordenarlas por idiomas, como hice con las plantillas de fuentes latinas y recientemente también con una vasca. dentro de las subpáginas se podría incluir índices (autor, año, título, etc.). --Ninud (discusión) 09:39 23 abr 2016 (UTC)

Me parece genial. Según vaya utilizando iré categorizando. Yo las vería mejor ubicadas en la categoría raíz del idioma antes que en XX-Español, pero sin problemas. --83.60.168.206 09:57 23 abr 2016 (UTC)

Tech News: 2016-17

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

Problemas

• Wikimedia probó un nuevo centro de datos la semana pasada. Esto significó que las wikis pudieron ser leídas pero no editadas durante 45 minutos el 19 de abril y 20 minutos el 21 de abril. [21]
• Cuando el centro de datos fue probado, las ediciones nuevas no se mostraron en el registro de cambios recientes durante 20 minutos. Ya se encuentran en el registro. Puedes leer más acerca de cómo encontrar las ediciones.
• Las notificaciones sin leer a veces se contaban de manera incorrecta. Esto ya fue corregido. [22]

Cambios esta semana

• Wikimedia Commons tendrá mejor acceso a Wikidata. Podrán utilizar los datos de cualquier página de Wikidata en cualquier página de Commons a partir del 26 de abril. [23]
• Será más sencillo indicar que desear ver los archivos que has subido con el asistente de subidas. [24]
• La nueva versión de MediaWiki se instalará en las wikis de prueba y en MediaWiki.org el 26 de abril, en todas las wikis que no son wikipedias y en algunas wikipedias el 27 de abril y en las wikipedias restantes el 28 de abril (calendario).

Reuniones

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

Cambios futuros

• El botón «Guardar la página» presente cuando editas ahora se llamará «Publicar». Esto es para ayudar a los editores nuevos a comprender lo que hace. Ya funciona de esa forma en algunas wikis. [25]

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

21:02 25 abr 2016 (UTC)

entradas de hitita cuneiforme y otras lenguas muertas con escrituras extrañas (a la romana)

hace tiempo ya que quería crear algunas herramientas, tablas de conjugaciones, de declinaciones, etc., para el hitita, que dentro de todo es una lengua relativamente simple (en comparación a las otras lenguas indoeuropeas antiguas), y además, de gran importancia por ser el testimonio indoeuropeo escrito más antiguo.
inicialmente se presenta una dificultad:

• la escritura (por no ser un alfabeto). en wikcionario se comenzó con la cuneiforme (3 entradas), pero la verdad es que no tiene mucha utilidad registrarlas así (que pocos dominan esta escritura y nadie tiene acceso a un teclado cuneiforme - nerds excluidos ;P). en cambio deberíamos utilizar las transliteraciones (como todos los diccionarios y libros de lingüística hitita).

lo que propongo es de crear las entradas según los diccionarios modernos (Kloekhorst 2008, Puhvel 1984-2013-aún incompleto). es decir, usar como lemas las bases léxicas romanizadas, y las entradas en cuneiforme como entradas secundarias.
podría ser como en lāman, o algo por el estilo. --Ninud (discusión) 14:30 29 abr 2016 (UTC)