Estoy de acuerdo en parte con vosotros.
Por un lado, sigo manteniendo que yo, si es posible, utilizaría un
mecanismo basado únicamente en la vista para averiguar la traducción de
cada valor posible de cada atributo.
En el formulario de entrada que propone Daniel, en el modelo relacional
guardaría únicamente un dato obtenido a partir del valor en uno de los
idiomas, y daría de alta las traducciones a nivel de vista.
Es decir, y obviando la frivolidad :), de
Nombre: Juan Sin Miedo (es)
John Fearless (en)
Descripción: Responsable de RRHH (es)
HHRR Manager (en)
Aficiones: Pescar (es)
Fishing (en)
introduciría en la bd:
pk: 3
nombre: john.fearless
descripcion: hhrr.manager
aficiones: fishing
y paralelamente en el mecanismo de internacionalización, se
introducirían las traducciones.
Estoy relativamente de acuerdo en que, si los datos son numerosos, más
aún lo serán sus traducciones, y por ello el mecanismo estándar basado
en ficheros de propiedades puede no ser indicado. En ese caso, guardaría
las traducciones de otra manera, en una bd relacional si es necesario,
pero siempre trataría de mantenerla asociada a la vista.
Aunque, por otro lado, si hay que realizar búsquedas sobre las
traducciones, entonces ya no se trataría de una adaptación del interfaz
únicamente, sino de los requisitos funcionales de la aplicación.
Para terminar, y sin tratar de demostrar mi opinión generalizada sobre
los patrones propuestos por Sun, yo no comparto demasiado el modelo que
proponen en este sentido. ¿No estaría más normalizado pensar en una
entidad "idioma", que particularizara el valor de los atributos
traducibles?
Se me ocurren dos modelos, dependiendo de las necesidades particulares.
Un saludo,
Jos
Attachment:
i18n.png
Description: PNG image
Attachment:
i18n-metadata.png
Description: PNG image
