i18n for the forms #9
Description
Actualmente hay identificadas un par de situación donde un soporte para i18n (o similar) a nivel librería resultaría de interés:
- Etiquetas de los formularios variables en función del país (Una necesidad de fonsagua y pmf). En general sería etiquetas asociadas a widgets (campos de la base de datos) pero también otros textos estáticos como títulos, pestañas,...
- Presentar al usuario nombres descriptivos para los campos de la base de datos. Por ejemplo en el combobox que permite ordenador el formulario por un campo. O en consultas como las de Siga donde el usuario puede escoger de una lista los campos a usar en el csv, y en el propio csv donde se usan nombres descriptivos para las columnas del csv.
- Sistema actual de alias de navtable
- En web también hemos necesitado de estos para consultas. En los modelos de SQLAlchemy se crean las columnas con un parámetro doc, tipo
myfield = Column(Text, Doc='My Field'). Ese 'My Field' es el valor que luego se muestra al usuario en algunos puntos de la web y se usa como cabecera en los reportes. La idea inicial aquí era vincular directamente en la bd campos con sentencias COMMENT que representaran el nombre largo pero SQLAlchemy no soporta COMMENT y SQLite tampoco lo hace directamente.
Implementaciones previas
Hay algún código relacionado con la tarea que se puede repasar para ver la problemática.
[BasicAbstractForm](https://github.com/iCarto/siga/blob/master/extAudasaCommons/src/es/icarto/gvsig/navtableforms/
BasicAbstractForm.java#L42) en Siga. Se ve como se coge el par nombrecampo - nombredescriptivo de un fichero properties para usar en la ventana de ordenar. Utils.getFields es donde se coge del properties el nombre de la bd y el alias (cualificados por esquema y tabla porque pueden ser traducciones distintas)
ConsultasPanel llama a CustomiceDialog donde los campos se muestran en JList y en comoboboxes.
El usar una clase como Field para guardar la información luego nos permite más cosas, como usar esa clase directamente en comboboxes (se renderizar el nombre descriptivo gracias al toString), implementa Comparable para poder mostrar los campos ordenados alfabéticamente,...
En web api/listados.py
Requisitos
- En el abeille debe haber un método que permita identificar a las etiquetas. Este identificador debería tener una vinculación con las columnas de la bd
- En el abeille el resto de textos estáticos, títulos, pestañas, también deben tener un identificador
- El almacen de las traducciones debe ser flexible. Si sólo trabajamos en escritorio un properties será lo más habitual, pero en sistemas que mezclen web y escritorio, esas traducciones podrían estar en una tabla de la base de datos.
- En principio la misma implementación debería dar solución a i18n las etiquetas del abeille y la traducción de nombres bd a nombres descriptivos. Si se complicara podrían ser soluciones distintas
- No tomar como prioritario. Pero 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
- Cuidado con no repetir los identficadores (name) en el abeille, porque es habitual usar
form.getComponentByName("name") - En ocasiones puede ser necesario tener dos traducciones para un campo, una "larga" que es la más habitual de usar para etiquetas, y otra "corta" más habitual para Comboboxes. Habrá que pensar si dar soporte a esta doble traducción en Field (o el objeto que sea) mediante un short_description y long_description. Aunque en este caso habrá que validar el comportamiento del toString. En el almacenamiento de la traducción se podrían usar una nomenclatura como tabla.campo.jlabel y tabla.campo.cbox o más genérico como tabla.campo.short y tabla.campo.long
Relacionado: #23