Closed cosmoscalibur closed 5 years ago
@cosmoscalibur, no es un error, sino una característica de Hunspell. Se llama twofold suffix stripping y permite reducir en teoría la cantidad de reglas de afijación y de banderas aplicadas a los lemas. En algún momento yo hice esas modificaciones, pero seguramente hay muchos otros lugares donde se podría aprovechar tal característica y no se hace.
Mira https://www.systutorials.com/docs/linux/man/4-hunspell/. Ahí figura la documentación sobre la característica.
El problema que menciona @RickieES en #203 es una limitación de la herramienta unmunch, que no maneja esas nuevas características de Hunspell. Sigue siendo casi la misma herramienta desde los orígenes y, si bien hay varios pedidos al respecto, no existe ninguna versión actualizada que maneje las características nuevas que aporta Hunspell sobre su antecesor MySpell.
La única manera de solucionar la limitación de unmunch es utilizarlo dos veces sobre el listado de palabras, en la primer pasada aplica todas las banderas directas que están en el listado de palabras y genera esas nuevas palabras etiquetadas (por la bandera del fichero de afijos). Al pasar el resultado de nuevo por unmunch esas pocas palabras etiquetadas terminan siendo modificadas y obtienes el listado definitivo.
Por eso es que podrán observar que en las aplicaciones como LibreOffice, Apache OpenOffice y Mozilla no se produce ningún error al manejar los diccionarios de esta forma, porque la biblioteca de funciones de Hunspell sí sabe como aplicar correctamente esta característica y produce el listado correcto de palabras.
@sbosio, aunque coincido en que me sorprendió la creación de este issue (@cosmocalibur, creo que vas a tener que hacer un backout del commit) :wink:, lo que sí es cierto es que el problema lo detecté precisamente en LibreOffice, que marca como erróneos lemas que debería considerar correctos aplicando en cadena los sufijos (el de una de las banderas del término original y el que tiene dicha bandera para, por ejemplo, generar el plural).
@RickieES @sbosio yo verifiqué con Code, Texmaker y Firefox. El error se reproduce en más de una herramienta, no solo unmunch.
He probado con la palabra "blanco". "blanco" está definido en Adjetivos.txt, así:
blanco/NGS
Y el sufijo N está definido así:
SFX N Y 19 SFX N a illa/S [bdfhjlmnprstv]a SFX N o illo/S [bdhjlmnprstv]o SFX N 0 cilla/S ve SFX N za cilla/S za SFX N 0 ecilla/S d SFX N ión ioncilla/S [cglnstx]ión SFX N ón oncillo/S [^i]ón SFX N 0 cillo/S or SFX N zo cillo/S zo SFX N 0 cillo/S [djlnu]e SFX N z cecillo/S z SFX N 0 ecillo/S ur SFX N e illo/S [cpt]e SFX N 0 illo/S [ls] SFX N 0 illo/S [^ou]r SFX N co quillo/S co SFX N go guillo/S go SFX N ca quilla/S ca SFX N ga guilla/S ga
He marcado en negrita la regla que se aplicaría a "blanco", observad que lleva a su vez el sufijo /S. He probado a escribir esto en LibreOffice:
Blanco, blanca, blancos, blancas, blanquillo, blanquillos
Y ninguna la marca como incorrecta. Así que, a menos que "blanquillos" se derive de algún otro sitio, la aplicación de dos sufijos encadenados funciona correctamente con carácter general. Es solo en algunos casos en los que está fallando.
@RickieES tan pronto llegue a casa devuelvo la acción en el archivo, para esperar una mayor validación de la causa del problema.
Yo tampoco logro reproducirlo con Firefox ni con LibreOffice. No sé si otras aplicaciones utilizarán un motor viejo de corrección que no es compatible con Hunspell.
En Firefox tengo configurado el idioma y diccionario de la distro que tengo instalada (Fedora) y en LibreOffice la extensión que generamos nosotros para Argentina. En ningún caso observo errores como pueden observar en las capturas de pantalla.
Usé para la prueba el lema causalidades. Está definido en el listado de palabras como causal/KS
y el afijo con bandera K a su vez incluye la regla SFX K 0 idad/S [lr]
, la única que puede generar correctamente ese plural. No existe ninguna otra entrada en el listado de palabras ni en los afijos que pueda generar ese lema, así que yo consideraría que la función de twofold affix stripping funciona correctamente.
Anexo captura que evidencia el problema en LibreOffice. Pruebo lemas recientes para validar que es la versión de desarrollo la que se encuentra instalada. Un hallazgo particular, no me reconoce "última" que debe generarse del lema "último/G". LibreOffice está configurado para usar Hunspell y tengo la versión 1.6.2 de Hunspell y la versión 6.0.7.3 de LibreOffice.
El caso de firefox si me equivoqué, no había ejecutado el reemplazo del archivo en share hunspell.
¿@sbosio me puedes compartir el número de versión de LibreOffice y Hunspell que tienes? Estoy verificando, "causalidad" y "causalidades" también es resaltada como errónea en mi LibreOffice.
@cosmoscalibur: Yo tengo la última versión actualizada en mi Fedora 29, que es LibreOffice 6.1.6.3, con la extensión 2.4 publicada.
Hice nuevas pruebas y, obviamente, no me reconoce los diminutivos de beso únicamente, pero apenas añado la bandera U al listado de palabras empieza a reconocerlos como válidos.
¿Alguna idea que podría ser @sbosio ? Estoy viendo que el lema "blasfemar" es una adición de hace 8 años, "causal" es de hace 12 años, "último" de hace 4 años. También me resalta errónea "válida". Entonces no tiene relación con la versión del repositorio. (edite el inicio del reporte para enfocarlo en lo que se ha aclarado).
Después múltiples intentos, llegué a una conclusión parcial, y es un error durante la compilación del archivo. Probando con la invocación directa de hunspell, también presento las dificultades mencionadas. Pero no solo eso, al usar el archivo de español España que venía por defecto, no tenía problema pero al reemplazarlo por el compilado de España, falla igual que el generado para Colombia.
#! /usr/bin/env bash
ORTOGRAF=$HOME/git/rla-es/ortograf
HERRAMIENTAS=$ORTOGRAF/herramientas
TMP=$ORTOGRAF/tmp
LANG=es_ES
cd $HERRAMIENTAS
. make_dict.sh --localizacion=$LANG
mv $LANG.oxt $TMP
cd $TMP
unopkg add $LANG.oxt # Instalar en LibreOffice
unzip -o $LANG.oxt
sudo mv $LANG.aff $LANG.dic /usr/share/hunspell/ # Usar a lo largo del sistema con Hunspell
Archivo de prueba e invocación de Hunspell
echo "causalidad blasfemable besito" > probrar
hunspell -d es_ES probrar
Sí @cosmoscalibur. Compilé un diccionario desde el repositorio y se observan los inconvenientes que mencionabas. Pero no están relacionados con el uso de la característica de Hunspell, sino con que en mi último commit al fichero de afijos no actualicé la cantidad de reglas del sufijo que modifiqué.
Ahora voy a subir una corrección y podemos dar esta discusión por terminada, ha sido un error mío. Hubiera jurado y puesto las manos al fuego con que había actualizado esos valores, pero se ve que no, y al no hacerlo el archivo de afijos se corrompe con resultados bastante impredecibles, según parece.
@cosmoscalibur. Si puedes actualizar tu copia de trabajo con este último commit y verificar si esto resuelve los inconvenientes detectados sería fantástico y podríamos dar por cerrado esta incidencia.
Muchas gracias, @sbosio, por darte cuenta. ¡Me estaba volviendo loco! :smile:
Ya me funcionan algunos de los diminutivos. He visto que otros no, pero porque no se pueden derivar a partir de la bandera U, lo comento en el issue 203.
@sbosio solucionado.
Actualización: Con el fin de mantener el foco en el problema, edito el inicio de esta discusión. El problema aparece en LibreOffice y posiblemente otras aplicaciones (posiblemente con un motor diferente a Hunspell). Sin embargo, LibreOffice configurado con Hunspell también presenta inconveniente para algunos usuarios (soy uno de ellos).
El error se presenta en lemas cuya formación depende de sufijos cuya regla contiene a su vez una bandera (sufijos A, B, C, F, H, J, K, L, M, N, P, Q, T, U). Se relacionan menciones en #145 y #203.
LibreOffice 6.0.7.3 Hunspell 1.6.2 Linux Mint 19 (tanto Hunspell como LO se instalaron del repositorio oficial) Diccionario generado para es_CO con la versión 6abbfdf938797095f9edfd77e7ec8b1c19bda348 (archivo de sufijos restaurado).