8000 Problemas con pospell · Issue #1352 · python/python-docs-es · GitHub
[go: up one dir, main page]

Skip to content

Problemas con pospell #1352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rtobar opened this issue Aug 21, 2021 · 3 c 8000 omments · Fixed by #1357
Closed

Problemas con pospell #1352

rtobar opened this issue Aug 21, 2021 · 3 comments · Fixed by #1357

Comments

@rtobar
Copy link
Collaborator
rtobar commented Aug 21, 2021

En versiones actuales de la rama 3.9 pospell falla al azar al analizar whatsnew/3.5.po, lo cual está bloqueando algunos PRs (pero no otros, dada la naturaleza intermitente del problema). Por ejemplo estas son dos corridas una justo después de la otra:

(python-docs) [rtobar@cronopio python-docs-es]---> while python scripts/create_dict.py && pospell -p dict.txt -l es_ES whatsnew/3.5.po; do echo "paso"; done; echo fallo
Created 'dict.txt'
paso
Created 'dict.txt'
paso
Created 'dict.txt'
whatsnew/3.5.po:1797:Oberkirch
whatsnew/3.5.po:2019:Oberkirch
whatsnew/3.5.po:2035:Oberkirch
whatsnew/3.5.po:2767:Oberkirch
whatsnew/3.5.po:2783:Oberkirch
whatsnew/3.5.po:2801:Oberkirch
whatsnew/3.5.po:2816:Oberkirch
whatsnew/3.5.po:2838:Oberkirch
fallo
(python-docs) [rtobar@cronopio python-docs-es]---> while python scripts/create_dict.py && pospell -p dict.txt -l es_ES whatsnew/3.5.po; do echo "paso"; done; echo fallo
Created 'dict.txt'
whatsnew/3.5.po:1797:Oberkirch
whatsnew/3.5.po:2019:Oberkirch
whatsnew/3.5.po:2035:Oberkirch
whatsnew/3.5.po:2767:Oberkirch
whatsnew/3.5.po:2783:Oberkirch
whatsnew/3.5.po:2801:Oberkirch
whatsnew/3.5.po:2816:Oberkirch
whatsnew/3.5.po:2838:Oberkirch
fallo
@cacrespo
Copy link
Collaborator
cacrespo commented Aug 22, 2021

Estuve haciendo unas pruebas en #1346 impactando ajustes sobre dict.txt y sobre el .po en cuestión pero sin resultados positivos. 👎
Tal vez la traducción se hizo a partir de una rama desactualizada (o algo por el estilo). Tampoco.
#1354 tiene el mismo problema. Cambié Oberkirch por OberKirch en 3.5.po (estaba de las dos maneras en el original) y ahora pasa sin problemas ¿?

@clacri ¿se te ocurre algo?

@rtobar
Copy link
Collaborator Author
rtobar commented Aug 22, 2021

El problema al parecer es provocado por el hecho de que Oberkich aparece de dos formas distintas (Oberkich y OberKirch), pero sólo si las palabras aparecen en cierto orden en el diccionario.

Cada vez que se genera dict.txt, estas dos palabras aparecen en distinto lugares del archivo (porque create_dict.py loopea sobre un set, los cuales no especifican orden de iteración), lo que explica por qué a veces ocurre el problema y a veces no. Por ejemplo éstas son dos corridas una después de otra:

$> python scripts/create_dict.py && grep -n Ober[kK]irch dict.txt
Created 'dict.txt'
266:Oberkirch
2763:OberKirch
$> python scripts/create_dict.py && grep -n Ober[kK]irch dict.txt
Created 'dict.txt'
302:OberKirch
3277:Oberkirch

pospell internamente llama a hunspell, que es quien hace el chequeo ortográfico finalmente. Sacando ya 3.5.po de la ecuación, podemos simplificar el problema mucho más:

$> python scripts/create_dict.py && grep -n Ober[kK]irch dict.txt; echo -e 'Oberkirch\nOberKirch' | hunspell -d es_ES -p dict.txt -a; echo -e 'OberKirch\nOberkirch' | hunspell -d es_ES -p dict.txt -a
Created 'dict.txt'
839:OberKirch
3319:Oberkirch
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)
& Oberkirch 1 0: OberKirch

*

@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)
*

& Oberkirch 1 0: OberKirch

$> python scripts/create_dict.py && grep -n Ober[kK]irch dict.txt; echo -e 'Oberkirch\nOberKirch' | hunspell -d es_ES -p dict.txt -a; echo -e 'OberKirch\nOberkirch' | hunspell -d es_ES -p dict.txt -a
C:reated 'dict.
8000
txt'
346:Oberkirch
3336:OberKirch
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)
*

*

@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)
*

*

En el primer caso OberKirch aparece antes que Oberkirch en el diccionario, y hunspell se queja diciendo que Oberkirch debiera ser cambiado por OberKirch (independiente del orden en que aparecen las dos palabras en el texto a revisar). Cuando Oberkirch aparece antes que OberKirch en el diccionario entonces no hay ningún problema.

Lamentablemente la solución no es simple:

  • No se puede sacar OberKirch del diccionario, porque de hacerlo hunspell sugiere cambiar OberKirch por Oberkirch.
  • Si intentamos darle estabilidad al orden de las entradas de dict.txt usando sorted() en create_dict.py entonces OberKirch aparece antes que Oberkirch, lo cual produce el problema.
  • Incluso si se fuerza a que Oberkirch aparezca antes en dict.txt, éste es sólo un caso en particular, y no resuelve el tema de fondo, que puede ocurrir nuevamente.

Leyendo un poco sobre hunspell hay maneras de especificar estas reglas más a fondo (al parecer el problema de fondo es que la misma palabra está escrita con distinta combinación de mayúsculas/minúsculas, lo que no es algo aceptado por defecto). Habría que investigar un poco más a ver qué se puede hacer al respecto.

Por otro lado me fijé qué hacen en otros grupos. En python-docs-pt-br el workflow en GitHub actions corre pospell también, pero tiene un pospel .... || true (acá) así que nunca falla. En cambio, lo que hacen es recoger todos los errores y subirlos como artefacts.

@cacrespo
Copy link
Collaborator
cacrespo commented Aug 23, 2021

Dejo constancia de lo que conversamos al respecto:
Dado que OberKirch / Oberkirch se refiere efectivamente al mismo apellido vamos a unificar en la traducción y de esa manera evitamos que fallen los tests sin alterar la configuración de pospell o hunspell.
Si están OK damos por cerrado el issue.

rtobar added a commit to rtobar/python-docs-es that referenced this issue Aug 29, 2021
Nótese que "Ghz" no es reconocida como una palabra válida, pero "GHz"
sí, incluso si "Ghz" se agrega al diccionario. Esto es probablemente un
problema similar al explicado en python#1352, por lo que la solución más
simple es no usar la forma original de la palabra en la traducción, y em
cambio usar "GHz".

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
cmaureir added a commit that referenced this issue Aug 31, 2021
 Traduce library/profile.po

Nótese que "Ghz" no es reconocida como una palabra válida, pero "GHz"
sí, incluso si "Ghz" se agrega al diccionario. Esto es probablemente un
problema similar al explicado en #1352, por lo que la solución más
simple es no usar la forma original de la palabra en la traducción, y em
cambio usar "GHz".

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Co-authored-by: Cristián Maureira-Fredes <cmaureir@users.noreply.github.com>
cmaureir added a commit that referenced this issue Dec 7, 2021
 Traduce library/profile.po

Nótese que "Ghz" no es reconocida como una palabra válida, pero "GHz"
sí, incluso si "Ghz" se agrega al diccionario. Esto es probablemente un
problema similar al explicado en #1352, por lo que la solución más
simple es no usar la forma original de la palabra en la traducción, y em
cambio usar "GHz".

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Co-authored-by: Cristián Maureira-Fredes <cmaureir@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
0