Ficheros de afijos erróneos

[Almorca]

Al ejecutar el commit c8653d4 se han dejado los ficheros de afijos locales inconsistentes. Hay que generar los nuevos ficheros de afijos (por lo menos el de es_ES) a partir del nuevo fichero de afijos común.

[RickieES]

Repito aquí mi comentario sobre el commit, para dejar la discusión en el issue.

Tras el commit c8653d4 hay otro [1], así que habría que considerar los dos. Lo que no encuentro es un script que haga ese cambio, y me parece inviable mantener manualmente los parches de todas las variantes.

Veo que tú hiciste un cambio en los afijos hace tiempo y actualizaste todos esos parches. ¿Recuerdas cómo lo hiciste?

[1] 0b06071#diff-c1e1f6ffbaebc5786ea65c523aa85e44

[Almorca]

Por lo que recuerdo hay que hacerlo a mano modificando el fichero de afijos para cada localización. Se puede automatizar la generación de los ficheros de afijos y la posterior generación de los nuevos ficheros patch pero las nuevas definiciones hay que meterlas a mano. Voy a ponerme ahora a modificarlos ficheros en mi equipo. Lo que no sé es como gestionar esto en el repositorio ya que mis conocimientos de git son muy limitados. ¿Sé puede anular sólo el commit afectado dejando los posteriores o si hay que eliminar todos los commit y volverlos a subir?

[RickieES]

Revertir un commit específico se hace así:

git revert $id

donde $id es el identificador de la revisión que queremos anular, en este caso supongo que con c8653d4 será suficiente.

[RickieES]

He estado preguntando en la comunidad de Mozilla Hispano y me han ofrecido una posible solución a largo plazo para evitar tener que mantener a mano los parches, o incluso los afijos regionales definitivos.

La propuesta sería la siguiente:

En la rama master se incluye sólo el afijos.txt genérico. Cada variante regional se añade como una rama (branch).

De partida, el fichero afijos.txt de todas las ramas es el mismo. A continuación, se añadirían los cambios en cada variante regional para dejarlas como se desea tener el fichero afijos.txt completo para cada una de esas variantes.

Cuando llega el momento de efectuar un cambio al afijos.txt, se realiza y se sube a la rama master (git add, git commit). Y, a continuación, se hace git merge en cada una de las variantes con master. A veces ese merge será limpio, y otras será necesario ajustarlo a mano. Al terminar con todas las variantes, se vuelve a la rama master.

La ventaja de tenerlos en cada rama es que cada variante irá evolucionando independientemente, y el git merge con la master los pondrá al día.

Tengo dudas con algunos detalles como qué pasa con los archivos genéricos (p.e.: RAE/Adjetivos.txt) en las ramas regionales. Las he preguntado a mis colegas, pero voy contando la propuesta aquí para que podáis aportar sugerencias.

[Almorca]

El problema del fichero de afijos es que las reglas tienen una cabecera con el número de líneas que le aplican. Esto hace que el incluir una nueva línea en el fichero de afijos no se pueda automatizar, ya que incluir dicha línea implica incluir la línea y sumar 1 al número de reglas en dónde se engloba.

Otro tema aparte es como gestionamos el tema de los diccionarios locales. Yo por ahora no gastaría esfuerzos en cambiar nada ya que para 3 desarrolladores que somos no creo que merezca la pena montar más lío. Si algún día se une más gente que quiere colaborar sólo un diccionario de alguna lengua entonces puede que sí que nos compense hacer una separación más clara dentro del repositorio.

[RickieES]

Sobre lo de incrementar el contador de reglas, eso sí parece fácil de automatizar con un script. Es decir, primero se aplicarían los parches y después se ejecutaría un script que cuente el número de líneas que tiene realmente cada regla, modificando si es necesario el valor que figura en la cabecera de cada una.

Por ejemplo, si tenemos una regla así:

SFX B Y 3
SFX B r dura/S [aií]r
SFX B r dura/S [^s]er
SFX B er idura/S ser

que una variante regional tuviera una línea más (me la invento):

SFX B Y 4
SFX B r dura/S [aií]r
SFX B r dura/S [^s]er
SFX B er idura/S ser
SFX B or odura/S sor

si se añade una línea más en el fichero neutral de afijos, esa variante quedaría así antes de pasar el script:

SFX B Y 4
SFX B r dura/S [aií]r
SFX B r dura/S [^s]er
SFX B er idura/S ser
SFX B or odura/S sor
SFX B ur udura/S sur // nueva línea añadida

y el script leería el fichero regional de afijos (no el parche, sino el completo) y encontraría la discrepancia. Es fácil, se leen en memoria todas las líneas de cada regla, se cuenta el número de líneas leídas, se actualiza el contador en la primera línea, y se vuelcan todas:

SFX B Y 5
SFX B r dura/S [aií]r
SFX B r dura/S [^s]er
SFX B er idura/S ser
SFX B or odura/S sor
SFX B ur udura/S sur // nueva línea añadida

Ahora no es prioritario, pero es algo que se podría explorar.

[Almorca]

Mientras buscamos una solución definitiva a la gestión de afijos locales he modificado el diccionario para que los afijos locales dejen de estar en formato parche ya que es un paso que simplifica el pasar el diccionario a formato UTF-8.