I18n support

[jorgelf]

Base i18n support for NavTableForms.
JavaDocs contain an explanation on its syntax, and fonsagua has another i18n branch with an example of its use.

[fpuga]

Tiene buena pinta, y me gusta que la API esté documentada. Si se pudiera meter algún test sería genial.

Un par de comentarios:

AbstractSubForm.Los cambios deben ser aplicados también en AbstractSubForm. Como el flujo en SubForm y Form es ligeramente distinto yo lo metería ya, para ver si sobreescribir initGUI es la mejor opción o igual se puede hacer directamente en el constructor que suele ser lo preferido en SubForm.

Tablas empotradas. Estaría bien reflexionar en si esto soluciona traducir las cabeceras de las tablas empotradas ( #23 ) y probar a hacer un ejemplo.

Configuración vs Código. No prioritario. Este punto lo tengo menos claro, pero valoraría la opción de definir getI18nResources() a través de los ficheros de rules para no tener que sobreescribir el método, permitiendo sobreescribirlo si no se quiere configurar en rules o se desea una configuración que no está contemplada en rules

Orden de visualización. No prioritario. He añadido un punto en los requisitos. El del orden. Por si se le puede dar una pensada:

Habrá ocasiones en que no tenga sentido presentar campos en un orden alfabético. Si están almacenados en una tabla en la bd la estrategia habitual es que haya una columna a mayores (orden) que defina el orden. Puede ser interesante estudiar si una estructura como Field u otra podría soportar una ordenación de este tipo

Visibilidad de objetos. Un formulario (que herede de AbstractForm / AbstractSubForm) probablemente tenga que tener acceso al I18nResourceManager. Por ejemplo al construir el panel de ordenar el formulario te hace falta generar Field o lo que sea y para eso hace falta acceso a I18nResourceManager. Esto sería lo más flexible, pero también podría existir en alguna clase un método toFields o parecido que me devuelva una lista de esos objetos directamente.

Sobre el token i18nkey. En general los ficheros de properties o incluso las tablas de la bd se generaran mediante scripts a partir de un modelo de datos. Así que tengan una forma complicada tipo nombre_esquema.nombre_tabla.nombre_campo.short = TEXTO no será problemático. Pero escribir todo eso en abeille es farragoso porque aunque copies y pegues, por ejemplo al editar al no aparecer todo el name en la caja de texto tienes que jugar mucho para ver donde están los errores y se puede perder mucho tiempo. Valorar si puede tener sentido en el abeille escribir sólo i18n.nombre_campo y que luego el código pueda buscar en el properties el valor nombre_esquema.nombre_tabla.nombre_campo.long automáticamente o algo parecido. Podrían ser más utility methods en JavaBundleI18nResource o incluso una clase nueva.

sqlite vs postgresql. No prioritario. Relacionado con el punto anterior, si se puede hacer como comento evitamos el problema de tener el mismo proyecto sobre sqlite y postresql, donde en sqlite no se puede cualificar por esquema.

[jorgelf]

Comento sobre los puntos y sugerencias del anterior comentario:

AbstractSubForm.

Hecho, los he aplicado igualmente dentro de initGUI.

Tablas empotradas.

También hecho, ahora hay constructores adicionales sin arrays de alias para los AlphanumericHandlers. En estos casos se busca en los recursos i18n del formulario correspondiente. También se emplean estos recursos para recuperar las traducciones de los valores boolean/bit de las columnas (e.g. 'table_true_value'), pidiéndolos en última instancia a gvSIG si no se encuentran en otro sitio, para que sea retrocompatible con las versiones anteriores donde esos valores se ponían en el fichero properties de la extensión.

Configuración vs Código.

Es una buena idea. Lo contemplaré después del resto de funcionalidades importantes.

Orden de visualización.

No creo que esto sea competencia de i18n, parece más un tema del modelo y la lógica de negocio (la importancia que tengan ciertos campos en el contexto concreto), o al menos de maquetación. Yo contemplaría añadirlo en otro punto si el código no se complica demasiado.

Visibilidad de objetos.

Métodos añadidos. De hecho inicialmente los tenía en la primera versión pero en algún momento los quité, probablemente por error...

Sobre el token i18nkey.

Sip, la idea es crear nuevos recursos para casos concretos donde se puede necesitar un tratamiento distinto en la recuperación de la cadena, como sería este caso. La interfaz a implementar es sencilla, así que no sería un problema. De todos modos, aquí ha habido un cambio de enfoque a la hora de almacenar las cadenas (lo comento más adelante) que quita sentido a esa nomenclatura en muchos casos: antes había un único fichero properties en el cual había que diferenciar cadenas con mismo nombre de distintos formularios, mientras que ahora cada formulario tiene sus recursos i18n que pueden apuntar a ficheros properties distintos.

sqlite vs postgresql.

Creo que el cambio de enfoque comentado en el punto anterior y la posibilidad de definir recursos i18n con comportamientos complejos evita este problema (aunque quizás haya que detectar el driver SQLite en algún caso debido a las limitaciones de ese SGBD).

Otros puntos que estaría bien contemplar:

• Como podéis ver en los commits he añadido un recurso que pide las traducciones a gvSIG. ¿Creéis que deberíamos incluirlo siempre por defecto, pidiéndole las traducciones si no se encuentran en ningún otro recurso? Yo pienso que mejor no añadirlo para evitar traducciones indeseadas (mejor que quede la cadena que no una traducción no contemplada). Por ahora sólo se emplea para las traducciones de los valores booleanos/bits de las tablas, con el fin de que sea retrocompatible.
• Aunque se pueden crear nuevos tipos de recursos i18n en cualquier momento, puede ser buena idea elegir ya iniciamente dar más peso al enfoque de un fichero i18n por proyecto que emplea NavTableForms o al de un fichero i18n por cada formulario. Yo me he decantado por este último por ahora, empleando la misma filosofía que con los ficheros de metadata.

[fpuga]

Lo de las traducciones de gvSIG estoy de acuerdo contigo.

Sobre el token i18nkey y sobre si dar más peso a ún I18nResource o a otro, todavía no lo tengo claro. Yo lo dejaría estar porque hasta que lo usemos en dos o tres proyectos para las tres situaciones que tenemos (etiquetas, panel de ordenar formularios, consultas) creo que va a ser difícil afinar más.

[jorgelf]

I plan on starting tomorrow to migrate all fonsagua forms to this approach.
Work on this project and fonsagua will still continue on the i18n branches, so don't worry about commits in master that may break other projects, but if anyone has any suggestion or complaint, please post it ASAP.

[jorgelf]

Me he encontrado un problema con el enfoque de identificación de campos empleado hasta ahora. Los checkboxes son tanto un componente de entrada de datos como una etiqueta, y por su primera condición deben tener el nombre del campo en la BDD para funcionar correctamente al guardar y leer. Esto implica que no podemos ponerles el nombre con el formato i18n.
Formas que veo para gestionarlos:

• Quitar del nombre el token inicial i18n y buscar siempre una cadena según el nombre del campo.
• Hacer lo del punto anterior sólo para los checkboxes, ignorando el resto de fragmentos posibles (opciones de formateo).
• Quitar la etiqueta integrada en el checkbox y ponerlas siempre independientes, pero esto implica que al pulsar en ella ya no se activará automáticamente el checkbox.

[fpuga]

La 3 no me gusta. Implica retocar todos los abeille existentes.

Lo de tener que meter el token inicial en todos los "widgets traducibles" era algo que no acababa de ver claro del todo. Mi comentario con el título "Sobre el token i18nkey" iba un poco en esa línea. A pesar de esto me inclino más por la solución 1 que por la 2. Es pronto para saber que va a funcionar bien y que no y digamos que la 2 ya está implementada.

Supongo que optaría por algo como añadir a translateComponentText, que si es un checkbox haga algo como:

chb.setText(getTranslation(i18nPrefix + name, label.getText()));

[jorgelf]

El token i18n puede resultar innecesario en formularios nuevos, pero lo añadí para evitar traducciones indeseadas en abeilles previos. Quizás sea sobre-ingeniería, pero no quería romper proyectos antiguos. Si los demás lo veis innecesario, podemos quitarlo y ya evitamos este problema.
Por ahora supongo que la mejor solución es tratar los checkboxes de manera distinta como sugieres, ya que en cierto modo también lo son (introducción de datos + etiqueta).
BTW, en la rama i18n de fonsagua ahora hay varios formularios completos adaptados al soporte i18n (a falta de sus checkboxes, claro).

[fpuga]

Lo veo bien como está ahora :). Por cierto que si por tu parte viene bien, por la mía es un buen momento para que integres en master todo.

[jorgelf]

OK, he solucionado el caso de los checkboxes como comentamos, sin requerir que empiecen por i18n.
He encontrado un caso que podía dar problemas, y es que en ocasiones tenemos una etiqueta externa al checkbox antes de él (una manera de colocar manualmente la etiqueta a la izquierda en lugar de a la derecha como trae el checkbox). En estos casos sigue interesando igualmente vincular la etiqueta al campo del checkbox, por lo que debería tener el mismo id, lo cual resulta en que también el checkbox se traduciría. Esto lo he solucionado ignorando aquellos checkboxes que no presentan un texto ya en el abeille.
Resumiendo, se intentan traducir los checkboxes que:

• Tienen un nombre con el formato estándar i18n.
• Ya presentan un texto, sin importar si su nombre empieza por i18n.

En el segundo caso no es posible poner las opciones de formato (dd, html, upper...), así que el texto del fichero properties ya deberá ir correctamente formateado.
Si nadie ve problema, el lunes lo integro en master.

[jorgelf]

Integrado en la rama master.