Diferencia entre revisiones de «Wikcionario:Café»

De Wikcionario, el diccionario libre
Contenido eliminado Contenido añadido
Grillitus (discusión | contribs.)
Bot: Archivando 2 hilos
Línea 27: Línea 27:
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 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 [https://meta.wikimedia.org/wiki/Grants:IdeaLab/Research_team_editing 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 [https://meta.wikimedia.org/wiki/User:Micru User:Micru] on meta.
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 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 [https://meta.wikimedia.org/wiki/Grants:IdeaLab/Research_team_editing 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 [https://meta.wikimedia.org/wiki/User:Micru User:Micru] on meta.
<!-- Mensaje enviado por Usuario:Micru@metawiki mediante la lista en http://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=12060169 -->
<!-- Mensaje enviado por Usuario:Micru@metawiki mediante la lista en http://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=12060169 -->

== Revisión de [[Wikcionario:Estructura]] ==
'''No archivar hasta que se haya llegado a una solución'''

En la revisión de [[Wikcionario:Estructura]], bajo [[Wikcionario:Estructura#Etimolog.C3.ADa|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.<br />
siempre se puede exponer la morfología, por ejemplo para la forma verbal {{l+|es|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.<br />
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í:
<nowiki>=== Etimología ===</nowiki>
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).
<nowiki>=== Forma verbal ===</nowiki>
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í:

<nowiki>=== Forma flexiva ===</nowiki>
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).
<nowiki>=== Forma verbal ===</nowiki>
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... --[[Usuario:Ninud|Ninud]] ([[Usuario discusión: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 {{ep|etimología}} y {{ep|etimología2}} vacías, las {{ep|etimología}} con el primer parámetro tomando el valor <code>femenino</code>, <code>plural</code> o <code>sufijo</code>, y las {{ep|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, [[Usuario:Peter Bowman|Peter Bowman]] ([[Usuario discusión: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. [[Usuario:Peter Bowman|Peter Bowman]] ([[Usuario discusión: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 [[es:w:Wikipedia:Punto de vista neutral|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, <u>excepto las etimologías que omitimos porque nos da mucho trabajo...</u>" <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 {{ep|catafijo}} que vengo usando para subcategorizar en latín, por ejemplo {{l+|la|-o|-ō|num=1}} (sust.), {{l+|la|-o|-ō|num=2}} (adv.) y {{l+|la|-o|-ō|num=3}} (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 {{ep|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 {{ep|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 {{ep|morfología}})
:: --[[Usuario:Ninud|Ninud]] ([[Usuario discusión:Ninud|discusión]]) 13:52 18 ene 2016 (UTC)


===Estructuras especiales dentro de estructuras especiales===
dejando de lado los casos intratables, como {{l+|la|edere}} y {{l+|la|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 {{l+|es|sale}} (de {{l+|es|salir}} y {{l+|es|salar}}), {{l+|es|barro}} (de {{l+|es|barrar}} y {{l+|es|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 {{l+|es|barro}}:

<nowiki>=={{lengua|es}}==</nowiki>
===Etimología 1===
====Sustantivo masculino====
...
===Etimología 2===
====Sustantivo masculino====
...
===Forma flexiva 1===
{{plm|barrer}} + el sufijo flexivo {{l+|es|-o|num=2}}.
====Forma verbal====
;1: <nowiki>{{f.v|barrer|yo|pres|ind}}.</nowiki>
===Forma flexiva 2===
{{plm|barrar}} + el sufijo flexivo {{l+|es|-o|num=2}}.
====Forma verbal====
;1: <nowiki>{{f.v|barrar|yo|pres|ind}}.</nowiki>

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

...
===Forma flexiva===
====Forma verbal 1====
{{plm|barrer}} + el sufijo flexivo {{l+|es|-o|num=2}}.
;1: <nowiki>{{f.v|barrer|yo|pres|ind}}.</nowiki>
====Forma verbal 2====
{{plm|barrar}} + el sufijo flexivo {{l+|es|-o|num=2}}.
;1: <nowiki>{{f.v|barrar|yo|pres|ind}}.</nowiki>

sin olvidarse que también en español tenemos entradas más complicadas aún, como {{l+|es|barra}}, que además de partir de dos bases léxicas también se forman con varios sufijos flexivos (por cierto {{l+|es|-a|num=2}} 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.<br />
por ej., un análisis avanzado del sufijo flexivo {{l+|es|-aban}} (<code> ''-a-ba-n'': ''-a-'' (vocal temática), ''-ba-'' (morfema de tiempo y modo) y ''-n'' (morfema de persona y número)</code>) solo figuraría una vez en wikcionario, dentro del artículo del sufijo flexivo {{l+|es|-aban}}.<br />
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 :)<br />
--[[Usuario:Ninud|Ninud]] ([[Usuario discusión: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 {{ep|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: <nowiki>{{f.v|barrer|yo|pres|ind}}.</nowiki>
:* '''Morfología:''' ''barr-o'', raíz ''barr-'' + sufijo flexivo {{l+|es|-o|num=2}}.
;2: <nowiki>{{f.v|barrar|yo|pres|ind}}.</nowiki>
:* '''Morfología:''' ''barr-o'', raíz ''barr-'' + sufijo flexivo {{l+|es|-o|num=2}}.

:--[[Usuario:Ninud|Ninud]] ([[Usuario discusión:Ninud|discusión]]) 12:55 26 ene 2016 (UTC)
:: (corrijo indentación (<code>:*</code>)) 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 ''[[Especial:PermaLink/4038167#Forma flexiva|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ść]]'' ([http://sgjp.pl/leksemy/#10557/ko%C5%9B%C4%87 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, [[Usuario:Peter Bowman|Peter Bowman]] ([[Usuario discusión: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 {{l+|pl|-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 [[Wikcionario:Referencia/LA/Morfología/Adjetivos#1..C2.AA_y_2..C2.AA_declinaci.C3.B3n|la primera y segunda declinación]] el sufijo flexivo {{l+|la|-o|-ō}} (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 {{l+|la|-o|-ō|num=x}}, ablativo {{l+|la|-o|-ō|num=y}}). por otro lado el plural del dativo y ablativo de todos los géneros en el clásico es {{l+|la|-is|-ī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 {{l+|la|-is|-īs|num=x}}, dativo y ablativo plural femenino {{l+|la|-is|-īs|num=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)
::: --[[Usuario:Ninud|Ninud]] ([[Usuario discusió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--[[Usuario:Esceptic0|Esceptic0]] ([[Usuario discusión: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|barra (Forma flexiva)]], con el mismo formato de {{ep|sinónimo}}, {{ep|antónimo}}, etc.:<br />
Morfología: base léxica + sufijo flexivo[enlazando a este]<br />
ej. {{l+|es|amemos}}:
*'''Morfología:''' am{{l+|es|-emos|num=2}}
(donde num=2 es subjuntivo presente de la 1ra conj.; mientras num=1 sería indicativo presente de la 2da conj., ej. {{l+|es|tememos}})<br />
luego en las entradas de los sufijos flexivos se puede dar toda la información (incluyendo la extenuante en torno a la segmentación).<br />
simple y elegante. sobre todo, no nos obliga a hacer ningún cambio en la estructura.<br />
<br />
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) --[[Usuario:Ninud|Ninud]] ([[Usuario discusión: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'''
:<s>{{+}}, como comenta Peter, ya lo aplicamos en casos que se combinan formas base con formas flexivas --[[Usuario:Ninud|Ninud]] ([[Usuario discusión:Ninud|discusión]]) 13:52 18 ene 2016 (UTC)</s> 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) --[[Usuario:Ninud|Ninud]] ([[Usuario discusión:Ninud|discusión]]) 12:59 26 ene 2016 (UTC)
# {{+}}, [[Usuario:Peter Bowman|Peter Bowman]] ([[Usuario discusión:Peter Bowman|discusión]]) 01:59 24 ene 2016 (UTC)
2. '''Etimología'''

3. '''Sin título''', bajo la acepción con la plantilla {{ep|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 {{l+|es|barra}}).
# {{+}}, 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. --[[Usuario:Ninud|Ninud]] ([[Usuario discusión: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>''' --[[Usuario:Ninud|Ninud]] ([[Usuario discusión:Ninud|discusión]]) 10:42 9 abr 2016 (UTC)

== [[m:Special:MyLanguage/Tech/News/2016/14|Tech News: 2016-14]] ==

<section begin="technews-2016-W14"/><div class="plainlinks mw-content-ltr" lang="es" dir="ltr"><div class="plainlinks">
'''[[m:Special:MyLanguage/Tech/News|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 [[m:Special:MyLanguage/Tech/News/2016/14|traducciones]] disponibles.

'''Cambios recientes'''
*Puedes filtrar [[m:Help:Special page#Logs|Especial:Registro]] de forma más detallada. [https://phabricator.wikimedia.org/T20954]
*Las wikis de Wikimedia ahora tienen una nueva forma de contar visitantes. [http://blog.wikimedia.org/2016/03/30/unique-devices-dataset/]

'''Cambios esta semana'''
* <span title="Elemento recurrente">[[File:Octicons-sync.svg|12px|link=]]</span> La [[mw:MediaWiki 1.27/wmf.20|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 ([[mw:MediaWiki 1.27/Roadmap|calendario]]).

'''''[[m:Special:MyLanguage/Tech/News|Noticias técnias]]''' preparadas por [[m:Special:MyLanguage/Tech/Ambassadors|embajadores técnicos]] y publicadas por un [[m:Special:MyLanguage/User:MediaWiki message delivery|bot]] • [[m:Special:MyLanguage/Tech/News#contribute|Contribuye]] • [[m:Special:MyLanguage/Tech/News/2016/14|Traduce]] • [[m:Tech|Obtén ayuda]] • [[m:Talk:Tech/News|Opina]] • [[m:Global message delivery/Targets/Tech ambassadors|Suscríbete o desuscríbete]].''
</div></div> <section end="technews-2016-W14"/> 22:13 4 abr 2016 (UTC)
<!-- Mensaje enviado por Usuario:Johan (WMF)@metawiki mediante la lista en https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=15501448 -->


== Tenemos editor visual !!! ==
== Tenemos editor visual !!! ==

Revisión del 18:28 30 abr 2016

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í

Atajo:
WN:C
Esta página es archivada por Grillitus. (info)

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)[responder]

Cuál tabla de conjugación? Tmagc (discusión) 02:45 1 mar 2024 (UTC)[responder]
La de los verbos en español. Rodrigo5260 (discusión) 16:46 1 mar 2024 (UTC)[responder]
O eso solo pasa en móvil y en la pc se ve normal? Rodrigo5260 (discusión) 16:47 1 mar 2024 (UTC)[responder]
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)[responder]
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)[responder]
@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)[responder]
@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)[responder]
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)[responder]
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)[responder]

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)[responder]

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)[responder]
@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)[responder]

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)[responder]

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)[responder]
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)[responder]
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)[responder]
¿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)[responder]
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)[responder]
@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)[responder]
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)[responder]
@Tmagc, gracias por revisar, saludos, 200.68.186.243 (discusión) 20:39 25 feb 2024 (UTC)[responder]
¿Puedo poner a RoboJ2 el flag de bot? --Cvmontuy (mensajes) 12:12 1 mar 2024 (UTC)[responder]
@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)[responder]
@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)[responder]
Gracias Cvmontuy (mensajes) 10:50 3 mar 2024 (UTC)[responder]
@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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]

Noticias técnicas: 2024-10

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

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)[responder]

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)[responder]
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)[responder]
@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)[responder]
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)[responder]

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)[responder]

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)[responder]

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)[responder]
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)[responder]

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)[responder]

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)[responder]
@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)[responder]

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)[responder]

@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)[responder]
@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)[responder]
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)[responder]
@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)[responder]
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)[responder]
@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)[responder]
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)[responder]
@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)[responder]
@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)[responder]
@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)[responder]
@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)[responder]

Noticias técnicas: 2024-11

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

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

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

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)[responder]

Tu wiki estará en solo lectura pronto

Trizek (WMF), 00:00 15 mar 2024 (UTC)[responder]

¿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)[responder]

@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)[responder]

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)[responder]

@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)[responder]

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)[responder]

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)[responder]
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)[responder]
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)[responder]
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)[responder]
De acuerdo. Tmagc (discusión) 03:25 17 mar 2024 (UTC)[responder]
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)[responder]

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:

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)[responder]

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)[responder]

Noticias técnicas: 2024-12

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

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)[responder]

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)[responder]

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)[responder]

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)[responder]
¿Entonces lo decidiste solo tú? ¿Razones? --188.76.241.151 (discusión) 14:48 25 mar 2024 (UTC)[responder]
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)[responder]

Noticias técnicas: 2024-13

MediaWiki message delivery 18:56 25 mar 2024 (UTC)[responder]


Archivo de abril 2024

Wikcionario:Café/2024 04

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.

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)[responder]

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)[responder]
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)[responder]
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)[responder]

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)[responder]

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)[responder]
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 [28]. 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)[responder]
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)[responder]
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)[responder]
era por eso, gracias! :) --Ninud (discusión) 10:11 10 abr 2016 (UTC)[responder]
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)[responder]
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)[responder]
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)[responder]

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)[responder]
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 [29]--Esceptic0 (discusión) 20:47 16 abr 2016 (UTC)[responder]
ahí por ejemplo agregué la plantilla comentario [30] ¿que les parece?--Esceptic0 (discusión) 16:11 18 abr 2016 (UTC)[responder]
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)[responder]

20:44 11 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)[responder]

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
--Ninud (discusión) 11:58 13 abr 2016 (UTC)[responder]
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)[responder]
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)[responder]

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)[responder]

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 [40], 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)[responder]
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)[responder]
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)[responder]
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)[responder]
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)[responder]

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)[responder]

Destacados de Wikimedia Marzo 2016

Estas son las noticias destacadas del blog de Wikimedia en Abril del 2016
About · Subscribe · Distributed via MassMessage (wrong page? Correct it here), 18:39 18 abr 2016 (UTC)

20:40 18 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)[responder]

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)[responder]
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)[responder]
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)[responder]
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)[responder]
los subíndices están reservados para las homografías (llanta1, llanta2). 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)[responder]
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)[responder]

┌─────────────────────────────┘
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)[responder]
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)[responder]

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)[responder]
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)[responder]
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)[responder]

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)[responder]

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)[responder]

21:02 25 abr 2016 (UTC)

Wikidata

Se que Omegawiki no tuvo la aceptación que hubiera esperado, pero podríamos sacar unas ideas para implementar como usar las propiedades en plantillas como {{hiperónimo}} (propiedad en wikidata) y agregarlos y/o tomarlos directamente allá. No sería tan revolucionario pero creo que son pasos en la dirección correcta. Si alguien se anima a hacer alguna yo por ahí puedo copiar en las demás creo que hay que usar algo como {{#if:{{Propiedad|P582}}--Esceptic0 (discusión) 10:53 28 abr 2016 (UTC)[responder]

no estoy seguro a que te referís. usar la plantilla {{hiperónimo}} para que genere categorías? --Ninud (discusión) 11:15 28 abr 2016 (UTC)[responder]
Esceptic0: Wikidata aún no ha sido activada en los Wikcionarios, que yo sepa aún sigue en fase de desarrollo. Por otro lado, me parece que aquello no es una propiedad (empieza por "Q", no por "P", pero apenas he usado Wikidata). Un saludo, Peter Bowman (discusión) 11:58 28 abr 2016 (UTC)[responder]

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)[responder]