Usuario discusión:Llull~eswiktionary/Lab

Mi opinión[editar]

Problemas que le encuentro:

Al no pasársele como parámetros los números de sección ni el código de idioma, requiere de la creación de muchísimas plantillas individualizadas (del orden de varias docenas mínimo por cada idioma) y siempre podrá darse el caso de que un usuario necesite, por ejemplo, una plantilla para la subacepción "II.12b." de una palabra inglesa o para la subacepción "I.7d." de una palabra japonesa, y se encuentre con que la plantilla para la barra separadora específica no está disponible aún.

El poner los elementos sombreados cada uno en una plantilla que incluye el código de sombreado hace que se deje un espacio en blanco muy extenso entre cada elemento, lo que creo que afea bastante, y no creo que este enfoque ofrezca ninguna ventaja frente a poner el código de sombreado en su propia plantilla (llamándolas por ejemplo {{sombra-ini}} y {{sombra-fin}} si queremos que su función quede muy clara). Respecto al problema de no poderse incluir plantillas como parámetros de otra plantilla (hay por ejemplo una por ahí Plantilla:· para poner ya formateado el punto volado que indica dónde se puede separar una palabra a final de línea, y otras como Plantilla:suf-fem que ponen ya formateadas etiquetas como "sufijo de femenino" y están pensadas para ir dentro del apartado MORFOLOGÍA), la solución es simplemente hacer un par de plantillas de inicio y fin que actúen a modo de paréntesis, en lugar de una sola que tome el texto en bloque como parámetro (véase por ejemplo el código de chilaba, aunque nótese que al ir haciendo cambios en las plantillas, dicha entrada ha quedado "patas arriba" y necesita actualizar el formato).

P.D. Se me olvidaba comentar que la parte de traducciones creo que va mejor por un lado en secciones bilingües por lema e idioma de llegada, del estilo de abeja /IT (nótese que esa página necesita actualización de formato), análogas a las entradas de un diccionario bilingüe como los de español-inglés o español-francés, pues una parte muy importante de cualquier diccionario traductor es ofrecer notas y ejemplos de uso y contexto (cosa que obviamente no puede ponerse en una mera línea), y por otra parte en una sección multilingüe por conceptos (véase por ejemplo abeja (insecto), falta actualizar el formato incorporando el diseño con barras separadoras) donde se compara cómo un determinado concepto (no una palabra, que puede tener muchas acepciones) se expresa en todos los idiomas, ordenados por familia lingüística (lo que permite por ejemplo constatar de un vistazo la similitud en las palabras para el concepto "abeja (insecto)" entre las lenguas romances, entre las germánicas y entre las eslavas).

Uaxuctum 10:12 21 mar, 2005 (UTC)

Respondo los tres puntos de modo desglosado a como los has puesto tu:

El código de idioma sí que se subministra como parámetro. De hecho se siguen usando tus mismas plantillas pero a escondidas. Con tu método se debe indicar por un lado el parámetro del nivel y por otro el título. Ciertamente tiene la ventaja de necesitar menos plantillas(aunque sean las mismas para todos los idiomas) pero por el contrario es más lioso de cara al usuario. Del modo experimental de esta página sólo se requiere poner el número del apartado y directamente se fijará a la vez tanto el nombre de la sección como el nivel correcto sin que el usuario necesite conocer el mecanismo que hay detrás. Además también hay una variable que permite poner de modo automatizado y estandarizado el título (categoría o ámbito de la palabra). De hecho, quizás esté explicado en alguna parte, pero no acabo de entender cual es el procedimiento usado para separar las palabras en estos distintos apartados. Lo he respetado por qué quizás sea un tipo de clasificación habitual en lingüística pero no veo la norma que rige la separación.
Lo del espacio en blanco entre plantillas creo que se puede arreglar manipulando las mismas plantillas. De hecho, había mucho código HTML espaciador (<br>) que supongo que se podría poner en las plantillas para evitar ponerlo consiguiendo que quedase más regulado. Las plantillas de inicio y final de sombreado no las había visto en ninguna parte. En ábaco no estaban sino que había otra del mismo tipo con los mismos inconvenientes. Que no se pueda diferenciar · de · no es algo que me preocupe demasiado, la verdad, algo peor sería lo de sub-fem, pero he mirado donde se usa y algo así se podría usar en una plantilla llamada algo así como flexión-a que lo regulase automáticamente. El caso es que recuerdo que hace meses cuando se empezó a hacer plantillas de conjugaciones verbales hubo alguien que también hizo plantillas sobre las flexiones de las palabras pero no sé encontrarlas si es que todavía existen. En castellano no hay tantos paradigmas de flexibilidad y la mayoría pueden formularse de modo parecido a flexión-s.
La vedad es que no entiendo lo que me indicas en la posdata y los cambios que comporta que este formato no permite.

Llull 14:45 21 mar, 2005 (UTC)

Respuesta en profundidad, en la que intento explicar el porqué de los elementos conflictivos en la plantilla de estructura (que podrán ser mejorados, pero desde luego no estaban puestos por que sí o por mero capricho mío como si yo prefiriese un código recargado a otro más "ligero", sino que tienen detrás su buena razón de ser y son el resultado de varios meses de ensayos en que fui probando la mayoría de las ideas que estás volviendo a intentar tú):

Con sinceridad, no veo que unas plantillas así:

{{nivel1|ES|I.|bla|bla|bla|bla}}
{{nivel2|ES|I.1.|bla|bla|bla|bla}}
{{nivel3|ES|I.1a.|bla|bla|bla|bla}}

o así:

{{secc|ES|I.|bla|bla|bla|bla}}
{{acep|ES|I.1.|bla|bla|bla|bla}}
{{subacep|ES|I.1a.|bla|bla|bla|bla}}

o así si lo prefieres:

{{secc|I.|ES|bla|bla|bla|bla}}
{{acep|I.1.|ES|bla|bla|bla|bla}}
{{subacep|I.1a.|ES|bla|bla|bla|bla}}

sean más liosas o menos claras que unas así:

{{1.|ES|bla|bla|bla|bla}}
{{1.1.|ES|bla|bla|bla|bla}}
{{1.1.1.|ES|bla|bla|bla|bla}}

ofreciendo el primer enfoque la notable ventaja de no requerir la creación de docenas de plantillas específicas para cada posible número de sección, acepción y subacepción. Creo que debemos asumir que el usuario tiene claro que lo que quiere añadir es una acepción nueva, una subacepción dentro de otra acepción o toda una sección para una categoría gramatical (de modo que elegir entre llamar a la plantilla "secc", a la plantilla "acep" o a la plantilla "subacep" es trivial), porque si no tiene claro esto, tampoco tendría claro si llamar a la plantilla "1.", "1.1." ó "1.1.1.".

Nótese que la función de los parámetros identificativos de sección "bla|bla|bla|bla" que aparecen al final de las plantillas de arriba no es mostrarse como etiquetas visibles, sino servir de puntos de "anclaje" para permitir el enlazado de hipertexto a dicha sección por criterio semántico, esto es, sin depender de la numeración que lleve la sección en cuestión, de modo que no tengamos que saber de antemano que la acepción de araña como lámpara lleva la numeración I.2. (para poder enlazarla como [[araña#I.2.|araña]], que también sería posible), sino que con poner [[araña#lampara|araña]] funcione siempre el enlace independientemente de que luego pueda venir alguien y añadir otra acepción entre medias con lo que la numeración de la acepción lámpara pasaría a ser I.3. El permitir hasta cuatro identificadores distintos para una misma sección tiene el objetivo de facilitar este enlazado semántico, de modo que si uno en otra entrada pone un enlace a [[araña#lampara|araña]] funcione igual que si pone [[araña#mobiliario|araña]]. Para que este enlazado de hipertexto no se rompa, los identificadores han de ir escritos sin diacrítico alguno y sin espacios en blanco, ya que lo que hace la plantilla con dichos parámetros es incluirlos en un código HTML de tipo <div id="..."> y en un identificador "id" de éstos no pueden ir letras acentuadas ni espacios.

Respecto a las etiquetas tipo Matemáticas, Botánica, etc., se trata de etiquetas de campo semántico y son de uso común en todo tipo de diccionarios (siendo especialmente necesarias en los diccionarios bilingües), ya que por un lado clarifican a qué contexto se refiere la definición (o traducción) que sigue (p.ej. la primera acepción de araña se usa en el contexto de la zoología mientras que la segunda es válida en el contexto del mobiliario), y por otro permiten la búsqueda rápida de la acepción deseada (por ejemplo, si vamos buscando qué significa "araña" en el contexto de la minería, no necesitamos ir leyendo una por una todas las acepciones hasta dar con ella, sino simplemente mirar la etiqueta de campo semántico que preceda a cada una hasta dar con la que pone Minería, o simplemente buscar dicha etiqueta de una ojeada en el índice de la entrada —nótese que en la entrada "araña" aún no está implementado dicho índice, que sería algo similar a los índices en 然 (carácter) y catalán). De otra parte, no creo que incluir dichas etiquetas en las plantillas sea buena idea, puesto que por un lado generarlas no requiere más que ponerlas en cursiva (esto es, entre las familiares ''...''), y por otro, las plantillas requieren que dentro del código de cada una esté fijado lo que corresponde hacer con un número fijo y determinado de parámetros, y si un parámetro está fijado para ser mostrado visualmente pero al llamar a la plantilla se ha dejado dicho parámetro en blanco, ocurre que se mostrará en pantalla el propio código de anclaje del parámetro (esto es, algo del estilo de {{{1}}} plantado ahí en medio donde no viene a cuento). Sin embargo, no es posible fijar el número de parámetros de este tipo de etiquetas, ni rellenarlos todos siempre, puesto que también corresponden aquí etiquetas de área y registro, como México, Hispanoamérica, Murcia, argot, vulgar, obsoleto..., estando el número total indeterminado de antemano (puede ocurrir que una determinada acepción pertenezca al campo semántico X, sea de carácter coloquial y se use en 5 regiones, lo que requeriría, para una visualización correcta, de una plantilla específica que admitiese exactamente 1 parámetro de campo semántico, 5 parámetros de área y 1 parámetro de registro); véase las últimas acepciones de araña, ninfa y perra como ejemplo de la variabilidad en del número de etiquetas de este tipo. (Nótese que, a diferencia de este caso, en el caso de los hasta 4 identificadores ocultos de sección comentados en el anterior punto, no hay problema en dejarlos en blanco puesto que no se muestran visualmente y lo único que ocurrirá es que se cree un identificador oculto de sección con un nombre de tipo "{{{1}}}").

Es difícil controlar con el código cómo va a quedar visualmente el espaciado entre líneas, ya que suele ir generado automáticamente al insertar determinados elementos HTML. Es por ello que no es posible concatenar dos plantillas que generen cada una un sombreado sin que se muestre un excesivo espaciado entre los contenidos de ambas, y la única solución a esto es poner el código de sombreado una sola vez para cada bloque, lo que además permite poner un borde más ancho al comienzo y al final del bloque en conjunto, mejorando en mi opinión la apariencia visual. Además, no creo que realmente haya mucha diferencia en legibilidad o facilidad de uso entre un código así:

{{Uso|ES|suele emplearse en plural: '''ábacos'''.}}
{{sinonimia|ES|[[monograma]]}}

y un código así:

{{sombra|ES}}
*{{uso}}: Suele emplearse en plural: '''ábacos'''.{{fin}}
*{{sinon}}: [[monograma]]{{fin}}
{{fin-sombra}}

obteniéndose con el segundo una mejor presentación visual y mayor flexibilidad ya que permite emplear plantillas dentro del texto sombreado al no ir éste como parámetro de otra plantilla, aparte de que en mi opinión refleja de modo más explícito que lo que va entre

{{sombra}} y {{fin-sombra}} pertenece todo a un mismo un bloque de sombreado. También, dejar fuera de las plantillas los códigos wiki *... (que generan listas encabezadas por viñetas) permite crear subniveles en la lista que pueden ser útiles en ciertos casos (por ejemplo, dentro el apartado de TÉRMINOS RELACIONADOS puede ser pertinente hacer subapartados con el fin de presentar la información de manera más ordenada y clara, véase por ejemplo en la acepción I.1a. de ojo).

Respecto a los <br>, su misión es que a la hora de editar una sección (por ejemplo una subacepción) no se pierdan los dos saltos de línea necesarios para que la barra separadora de la siguiente sección aparezca lo suficientemente separada de la sección anterior. Quiero decir, si se ponen los dos saltos de línea al final de la sección como meros retornos de carro, al editar la sección y grabar el programa sólo guarda uno de ellos, provocando que no se produzca la separación visual necesaria una vez grabada la edición de la sección (la barra aparecerá "pegada" al bloque de sombreado de la acepción anterior), mientras que poniendo el último como <br> dicha separación no se pierde. Cierto es que estos <br> se podrían incluir en la plantilla de la barra separadora de la sección siguiente (y de hecho ya lo había probado yo para reducir el código visible), pero surge el problema de que cuando aparecen seguidas dos barras separadoras (como en el caso de las de I.1. y I.1a. en ninfa), la presencia de ese <br> provocaría un espacio en blanco demasiado grande entre ambas barras, lo que a mi modo de ver afea bastante la presentación; es por ello que si miras el código de dicha entrada verás que en ese caso no hay <br> antes de la plantilla de I.1a. Aunque ahora que lo pienso, creo que la solución puede estar en enmascarar ese <br>, cuya función puede no estar nada clara para muchos, en plantillas de cierre tipo {{fin-secc}}, {{fin-acep}}, {{fin-subacep}}, de modo que la inclusión de ese código de formato resulte más "intuitiva".

En cuanto a lo de las traducciones, el comentario se debe a la inclusión de la parte de traducciones dentro de la entrada monolingüe. Creo que, por diversas razones, es mejor no mezclar en una misma entrada la parte monolingüe de definición con la parte bilingüe de traducción.

Uaxuctum 21:40 21 mar, 2005 (UTC)