Wikcionario:Café

De Wikcionario, el diccionario libre
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]


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.

Sección de referencias en nueva estructura

Hola. Probé la nueva estructura en yam y creo que la sección de Referencias debería ser de tercer nivel (es de segundo), para que cada una quede anidada en el idioma (de segundo) o que la de idioma sea de primer nivel. En ambos casos las jerarquías se desordenan, pero la situación actual tampoco parece buena. Saludos. Lin linao ¿dime? 02:08 30 jun 2015 (UTC)[responder]

PS: Otra cosa es que habrá ciertas secciones que sean translingüísticas, como las distintas clases de símbolos (elementos químicos, unidades de medida), y las transliteraciones. Sobre lo segundo, en yam hay una transliteración del hebreo, que en mi opinión no debería figurar como hebreo a secas, pero por ahora no hay modo de anotarla. Saludos. Lin linao ¿dime? 02:31 30 jun 2015 (UTC)[responder]

Volveré a las transliteraciones en breve, es uno de los asuntos que me impiden progresar con la conversión.
En cuanto a las referencias, WN:ES contempla incluir una sección común a todas las lenguas, de modo que tu edición era incorrecta (el bot está programado para borrar las secciones de referencias repetidas e incluir una por defecto al pie de página, pero anoche no llegó a procesar esa página a causa de un error en el código, ya subsanado). La alternativa que propones debería ser discutida y aceptada para sustituir a la norma actual (personalmente descartaría los títulos de segundo nivel y con los tags <small>, es algo que estamos procurando evitar en la nueva estructura).
Este es también uno de los temas que quería discutir antes de la edición en masa. He encontrado unas 740 mil páginas que incluyen el título Referencias y notas, de modo que, siguiendo el esquema actual, el bot añadiría dicho título en las cerca de 100 mil entradas restantes. Partiendo de este punto, quería preguntar si hay interés por borrar las secciones de Referencias y notas si no se ha aportado ninguna referencia en la entrada (bien mediante tags <ref>, alguna plantilla o manualmente) y dicha sección se presenta vacía Las alternativas son:
  • (opción por defecto, pues es la norma actual) no borrar estas secciones aunque estén vacías, añadirlas en las 100 mil páginas restantes. Es posible escribir un gadget después de la transición que las oculte (nuevamente, solo si están vacías), si bien seguirían presentes en el wikicódigo de la página.
  • programar el bot para borrar las secciones vacías, detectando a tal efecto la presencia de tags <ref> u cualquier plantilla que los transcluya, valiéndose para ello de una lista predefinida (nota para mi yo futuro: utilizar una categoría de seguimiento una vez solventado phab:T69700)
Un saludo, Peter Bowman (discusión) 13:09 30 jun 2015 (UTC)[responder]
Gracias. No sabía que la idea era tener una sola sección de referencias. Pensaré sobre los dos temas: tener una sección o varias y qué hacer con las entradas en donde no hay referencias. Saludos. Lin linao ¿dime? 01:48 1 jul 2015 (UTC)[responder]
Personalmente no estoy de acuerdo con borrarlas o ocultarlas aunque estén vacías, es necesario fomentar la inclusión de referencias, no creamos contenido primario y en realidad no deberían existir entradas sin referencias, yo votaría de hasta le agregarles una nota cuando no haya referencias diciendo "Esta entrada no posee referencias, por favor si puedes incluye alguna"--Esceptic0 (discusión) 15:03 23 jul 2015 (UTC)[responder]
La inmensa mayoría de las entradas de Wikcionario son formas flexivas, luego nos podríamos preguntar para qué sirve una sección de referencias en una entrada como zapateéis. Por lo demás, su presencia no guarda tan estrecha relación con la inclusión de referencias como puede parecer en un principio. Recordemos que lo óptimo es añadir fuentes en el cuerpo de la entrada mediante tags <ref>, las cuales aparecerán en una nota al pie independientemente de que esta sección esté presente o no (el bot puede encargarse de añadirla si es conveniente, véase el segundo punto de mi anterior comentario). Por lo general, no hace falta que esta sección sea editada directamente. Un saludo, Peter Bowman (discusión) 17:18 23 jul 2015 (UTC)[responder]
totalmente de acuerdo, ahí agregué tu explicación a la plantilla para las futuras dudas que tengan los editores sobre para qué está. Yo había entendido mal y estaba eliminando el <br clear="all"/>--Esceptic0 (discusión) 11:25 7 ago 2015 (UTC)[responder]

Nueva estructura: <br clear="all">

Quisiera tratar en este hilo la presencia de estos elementos HTML en las entradas y su lugar tras la conversión a la nueva estructura. Para quienes desconozcan su función, aclaro que consiste en evitar que cualquier elemento flotante invada los elementos situados a continuación de dichos tags <br>, ya sea por la izquierda o por la derecha (esto último es lo más habitual). Los ejemplos más típicos de elementos flotantes son las imágenes o las tablas de flexión que vemos en el margen derecho de las entradas, así como la recientemente creada plantilla {{pron-graf}}. En las siguientes imágenes, tomadas sobre una versión editada de ransack con la tabla de flexión expandida, se puede apreciar la diferencia: imagen a, imagen b. Actualmente, no es necesario incluir ningún artificio adicional (como estos tags) para evitar el solapamiento de elementos respecto de los títulos de nivel 2 en la nueva estructura (secciones de idioma y referencias), pues se encargan de ello estas nuevas reglas que añadí recientemente a Common.css. Imagínese el efecto negativo que supondría que las imágenes, tablas de flexión, etc. de una sección de idioma invadiera el espacio de la siguiente, desplazando a su vez los elementos flotantes de esta y así sucesivamente.

Repasados los encabezamientos del nivel superior, queda analizar las subsecciones dentro de las propias secciones de idioma. Es muy frecuente que haya un <br clear="all"> justo delante del título de una sección que normalmente contiene una tabla u otro elemento que ocupa todo el ancho de la entrada. Es el ejemplo de las tablas de traducciones, locuciones o derivados de otras lenguas (aquí se aprecia que la última imagen desplaza una de estas tablas desplegables, generando un hueco vacío bajo el título Traducciones). Ninud me propuso insertar estos elementos antes de los títulos de etimología (en caso de haber más de uno). Veo dos alternativas:

  • Crear una plantilla, llámese por ejemplo {{clear}}, que sustituya a los <br clear="all"> (internamente podría contener un tag <span> o <div> para evitar ese salto de línea adicional que genera un <br>, aunque eso es lo de menos). El bot la añadiría automáticamente donde sea necesaria, y muy posiblemente borraría también otros usos que los editores le decidan dar y no se hayan consensuado antes (es un elemento que afecta a la presentación visual de la entrada, luego no se debería abusar de él). Obviando esto último, esta opción tan solo simplificaría el modo de empleo actual y favorecería la estandarización en caso de adoptar nuevas soluciones (no es raro encontrarse con plantillas de este tipo en otros proyectos).
  • Crear un accesorio escrito en JavaScript capaz de detectar las secciones afectadas y aplicarles la regla CSS correspondiente, no permitir el uso de ningún <br clear="all">. No funcionaría en clientes muy antiguos o en el caso de aquellos usuarios que decidan desactivar JS en su navegador, pero aún así no debería afectar más que aun número reducido de lectores (de todos modos, no sería la única funcionalidad de la que se verían privados).

JavaScript aquí no me parece una solución óptima, pero tampoco me convence la presencia en el wikicódigo de elementos aparentemente superfluos y potencialmente desconocidos para el editor novato, que en muchas ocasiones no llegan a cumplir su función a menos que sea añadida una imagen o tabla flotante. En este último caso, es posible que su número se vea reducido en el futuro (Wikcionario:Café/2015 04#declinación de adjetivos latinos). Aprovecho también para comunicar que mi intención es comenzar con el boteo dentro de unas dos semanas. Un saludo, Peter Bowman (discusión) 23:23 19 jul 2015 (UTC)[responder]

Nunca había entendido para que aparecía eso, lo dejaba por las dudas, hasta ahora. No está bueno que aparezca en el wikicódigo, si es con una plantilla por lo menos se puede explicar en la documentación de la misma para que se usa pero si se va a poner en todas las entradas sería conveniente que se ponga automáticamente y de forma oculta. No puedo decir más porque no tengo idea.--Esceptic0 (discusión) 14:51 23 jul 2015 (UTC)[responder]
Ante la duda, he preferido adoptar la primera solución, más cercana a la práctica actual. Podremos volver a esto en el futuro para recoger más opiniones y analizarlo otra vez. El bot ya ha empezado a colocar la recientemente creada plantilla {{clear}}. Concretamente, la inserta justo antes de aquellas secciones cuyo contenido empieza por una de las siguientes plantillas: {{arriba}}, {{rel-arriba}}, {{trad-arriba}} (ejemplo). La novedad está en que también colocará dicha plantilla antes de las secciones de tipo Etimología X, donde X > 1 (ejemplo; se puede ver que en la sección del Francés antiguo impide que {{pron-garf}} invada la siguiente sección etimológica, donde, por cierto, debería estar otra plantilla de pronunciación). Si alguien observa otro caso donde deba usarse {{clear}}, actualizaré el código para tenerlo en cuenta. Un saludo, Peter Bowman (discusión) 16:36 6 ago 2015 (UTC)[responder]

14:57 10 ago 2015 (UTC)

wikidata

Porqué razón wikidata todavía no tiene incorporado ningún wiktionary? lo harán en el futuro?. Siendo, creo yo, este el proyecto que mas se beneficiaría de esto--Esceptic0 (discusión) 10:32 13 ago 2015 (UTC)[responder]

Básicamente, debido a la complejidad del asunto y a la falta de disponibilidad de los desarrolladores :). Se ha realizado una serie de propuestas que puedes consultar aquí. Por lo que puedo ver, ya han empezado a buscar voluntarios para que inicien la primera fase de la última propuesta (centralización de los enlaces interwiki en los artículos del espacio de nombres principal; ver d:Wikidata talk:Wiktionary#First Step, d:Wikidata talk:Wiktionary/Development/Proposals/2015-05#Start?, phab:T987). Un saludo, Peter Bowman (discusión) 11:01 13 ago 2015 (UTC)[responder]
=( otra cosa que tampoco tenemos y sería beneficiosa para aumentar la cantidad de artículos nuevos por día es el editor visual, en el francés está implementado--Esceptic0 (discusión) 03:24 14 ago 2015 (UTC)[responder]
Me abstuve de votar al respecto en Wikcionario:Café/2015 01#Editor visual porque creo que no se han sopesado todos los pros y contras. Supongo que un editor experimentado apreciará la facilidad de edición de las plantillas, pero me parece que los novatos se perderán completamente (precisamente debido a ese mismo mar de plantillas). Vendría bien crear una especie de guía interactiva integrada en el Editor Visual que indicara qué elementos y en qué lugar se pueden añadir (p. ej. una nueva sección de idioma, una acepción, otra etimología) e impidiera alterar accidentalmente la estructura de las entradas.
Esceptic0: en el hilo archivado mencionaste la posibilidad de introducir citas con plantilla. En pl.wikipedia se usa un accesorio que podría traer aquí, funciona mediante un formulario (en esto se asemeja un poco a lo que tiene el Editor Visual) que se abre al pulsar un botón en la barra de herramientas de edición y solo hay que rellenar los campos, situar el cursor de texto en el lugar deseado y pulsar otro botón para insertar la plantilla: [42]. ¿Es una buena idea? Un saludo, Peter Bowman (discusión) 15:37 14 ago 2015 (UTC)[responder]
Todo lo que ayude es buena idea, pienso yo que un editor nuevo no sabe que borrar y que si no debe elegir que borrar y solo rellenar es mucho mas amigable--Esceptic0 (discusión) 20:13 14 ago 2015 (UTC)[responder]

Requiere extensión. Actualmente sólo permite tres palabras como antecedentes, pero debe ser cinco. Así que,

Del latín ad, de, in, illam y horam

En lugar de

Del latín ad, de e in

¿Me comprendes? --Romanófilo (discusión, contribuciones) 03:32 15 ago 2015 (UTC)[responder]

Romanophile: ¿podrías mostrar un ejemplo de uso en el que observas esa carencia? Me refiero a algo como {{etimología|prefijo|ad|de|in|...}}. La plantilla admite varios modos de funcionamiento y no consigo encontrar en el código el lugar exacto donde quieres añadir otros dos parámetros. Peter Bowman (discusión) 14:32 15 ago 2015 (UTC)[responder]
Peter Bowman: adineauri --Romanófilo (discusión, contribuciones) 10:51 17 ago 2015 (UTC)[responder]
Hecho, gracias: Especial:Diff/2878844. Un saludo, Peter Bowman (discusión) 11:24 17 ago 2015 (UTC)[responder]

Noticias destacadas de Wikimedia, julio 2015

Estas son las noticias destacadas del blog de Wikimedia en julio 2015
About · Subscribe · Distributed via MassMessage (wrong page? Correct it here), 15:05 17 ago 2015 (UTC)

16:17 17 ago 2015 (UTC)

Actualización sobre la herramienta de fusión global de cuentas

Estimados usuarios,

Como sabréis desde el equipo técnico de la Fundación se estaba trabajando en una herramienta que permitiese fusionar cuentas globales pertenecientes a un mismo usuario, en el marco del proceso de "finalización SUL". A pesar de los avances que en esa materia se han realizado, desde dicho departamento nos informan que, habiéndose elaborado un prototipo de herramienta, puesta en práctica, ésta ha resultado ser defectuosa, causando serios problemas y no funcionando correctamente con todos los componentes y extensiones de MediaWiki, ni con todas las bases de datos de Wikimedia.

Ello obliga a suspender, una vez más, la implantación de esta herramienta de fusión de cuentas sine die. No obstante os informamos de que ya se está trabajando en una nueva versión de la herramienta y que se espera que pueda estar disponible en el año 2016, aunque dicha estimación puede modificarse al alza o a la baja dependiendo del progreso y las complicaciones que vayan surgiendo entorno al desarrollo de la herramienta así como de la cantidad de personal que esté trabajando en ello. De todas formas, el proceso se prevé lento por la clasificación de herramienta accesoria que tiene este proyecto.

Además, y con el fin de paliar los problemas que se han detectado en esta fase de pruebas, el alcance de la herramienta será mucho más limitado frente al inicialmente previsto. En principio se estima que sólo aquellas cuentas que hayan sido afectadas por el proceso de finalización SUL podrán ser fusionadas, entre otras cosas de las que se nos irán informando.

Lamentamos que la puesta en marcha de esta funcionalidad se vea nuevamente frustrada por las complicaciones técnicas. Desde Meta-Wiki los stewards esperábamos poder empezar a atender solicitudes en breve.

Por ello os pedimos que no acudáis a Meta-Wiki a pedir nuevas fusiones de cuentas, pues éstas serán automáticamente denegadas al no poder ni siquiera estimar que se van a poder procesar en breve. Del mismo modo, aquellas peticiones ya realizadas se verán denegadas.

Un cordial saludo,
-- MarcoAurelio 09:26 18 ago 2015 (UTC)[responder]

Entregado por MediaWiki message delivery, el sistema de notificaciones en masa de MediaWiki.

ucf/plm, códigos de idioma

Lo que quiero consultar en esta ocasión son realmente minucias, pero me da grima pensar en editar 835k+ entradas para revertir una de ellas...

  • ¿Hay algún inconveniente en cambiar todas las llamadas de la plantilla {{ucf}} a {{plm}}? Aunque la primera parezca tener 668k transclusiones según Especial:PlantillasMásUsadas, esto se debe a que ella misma está transcluida en otras plantillas como {{forma verbo}}. En realidad solo hay 38k llamadas directas a {{ucf}} desde el wikicódigo de las entradas, unas 6 veces más que las que tiene {{plm}}. En Plantilla discusión:ucf se propuso redirigir la forma anglosajona (upper case first) a la española (primera letra mayúscula), de más reciente creación.
Tiene sentido que se prime la versión en castellano. Mientras no se asigne ningún código ISO a alguna de las abreviaturas, no veo mayor problema. --80.31.75.180 11:37 21 ago 2015 (UTC)[responder]
Buena observación. Parece que se llegó a usar el código plm para designar un dialecto del musi llamado palembang, al menos hasta que en el 2007 se decidió confluir este y los demás dialectos bajo el código mui ([51], [52]; el portal MultiTree registra una entrada para el palembang de musi bajo la designación no oficial mui-plm: [53]). Hoy dicho código no parece estar ocupado por ningún idioma ([54], [55]). Peter Bowman (discusión) 23:58 21 ago 2015 (UTC)[responder]
  • La plantilla {{lengua}} no distingue entre mayúsculas e minúsculas en el código de idioma (podemos escribir {{lengua|ES}}, {{lengua|es}} o incluso {{lengua|Es}}). Empecé adoptando la mayúscula por similitud con el nombre de las antiguas plantillas {{ES}} y {{XX-ES}}, y en un principio ese esquema sería adoptado en prácticamente todas las entradas tras la conversión. Por ese motivo, y pretendiendo mantener una coherencia interna, añadí una tarea que convierte el código a mayúsculas donde no aparezca así (ver Especial:Diff/2884175). Sin embargo, es una práctica habitual introducir dicho código en minúsculas en el parámetro leng de muchas plantillas, así como en el primer parámetro sin nombre de las plantillas de sección ({{sustantivo masculino|es}}). ¿Hay alguna preferencia por usar siempre las minúsculas a partir de ahora?

Un saludo, Peter Bowman (discusión) 11:06 21 ago 2015 (UTC)[responder]

Yo prefiero los códigos de idioma en minúsculas, que es como aparecen los códigos ISO 639-* y los códigos ad-hoc de Wikimedia, y ya que ahora en los encabezados aparecen como parámetro, deberían igualarse en mi opinión. Los encabezados en mayúsculas son parte de la herencia arrastrada, pero ya que se entra en faena veo más coherente la preferencia de las minúsculas que de las mayúsculas. Saludos --80.31.75.180 11:37 21 ago 2015 (UTC)[responder]
No tengo preferencia sobre las mayúsculas o minúsculas, sobre ucf a plm mientras no rompa nada por su puesto a favor A favor, hay que trasladar el código de ucf en plm y redirigir ucf a plm--Esceptic0 (discusión) 12:06 21 ago 2015 (UTC)[responder]
Prefiero las minúsculas en los códigos y plm si no se rompe nada. Sobre los códigos de idioma, haría falta una revisión de coherencia: iso 639-2 > iso 639-3 > ¿SIL (creo que siempre coincide con ISO, pero no estoy seguro), Linguistlist > Glottolog? Lin linao ¿dime? 16:15 21 ago 2015 (UTC)[responder]

Gracias por la pronta respuesta :). Seguiré con la conversión {{ucf}} → {{plm}}, y empezaré a usar las minúsculas por defecto. El bot efectuará el cambio de mayúsculas a minúsculas (será la misma tarea que comenté en el segundo punto, pero ahora invertida) si tiene que hacer algún otro arreglo en la entrada.

Otra de esas minucias: basándome en WN:ES y otras páginas similares supuse que no colocábamos ningún espacio alrededor de los títulos de las secciones, así que indiqué al bot que los eliminara (=== Título ======Título===). Sin embargo, dichos espacios aparecen en la versión actualizada de las plantillas de creación de lemas (p. ej. Plantilla:Plantilla Sustantivo) (también son automáticamente insertados por MediaWiki cada vez que creamos una nueva sección en el Café o en las páginas de discusión). Parece, pues, que su adopción es prácticamente un hecho consumado, pero no lo había reflejado en el código del bot; en un principio voy a actualizarlo para que no los borre o los inserte donde falten. Personalmente, creo que le confieren algo más de legibilidad al wikicódigo, siendo apenas dos bytes más por sección. Un saludo, Peter Bowman (discusión) 16:47 22 ago 2015 (UTC)[responder]

Estructura para transliteraciones

Hola en el wikcionario hay muchas transliteraciones, pero no tienen una estructura uniforme, ejemplos: menorah, adam. La documentación sobre la estructura del wikcionario no especifica el formato correcto, ¿Serian tan amables de completar la página de estructura para incluir el formato de una transliteración? De antemano gracias, --201.103.49.25 09:52 24 ago 2015 (UTC)[responder]

13:02 24 ago 2015 (UTC)

21:36 31 ago 2015 (UTC)

Introducing the Wikimedia public policy site

Hi all,

We are excited to introduce a new Wikimedia Public Policy site. The site includes resources and position statements on access, copyright, censorship, intermediary liability, and privacy. The site explains how good public policy supports the Wikimedia projects, editors, and mission.

Visit the public policy portal: https://policy.wikimedia.org/

Please help translate the statements on Meta Wiki. You can read more on the Wikimedia blog.

Thanks,

Yana and Stephen (Talk) 18:12 2 sep 2015 (UTC)[responder]

(Sent with the Global message delivery system)