Aplicacion multi lenguaje
9 views
Skip to first unread message
jmiguel rodriguez
May 6, 2013, 10:32:06 AM5/6/13
to grailsenc...@googlegroups.com, madri...@googlegroups.com
Hola a todos!
Una preguntilla, para animar un poco la tarde del lunes post-puente... :-).
En mi empresa estamos comenzando una aplicacion que tiene como
requisito ser completamente multi-lenguaje. No solo
ingles-castellano-aleman-etc como, tambien Catalán, Euskera y no se
Bable y Andalú.
Para la parte 'de la aplicación' con el soporte nativo de grails creo
que tendremos suficiente, pero el problema se nos plantea por la parte
de datos.
Por poner un ejemplo sencillo, en la 'entidad' (léase tabla, clase de
dominio o como queramos llamarlo) de ciudades tendria que guardar
"Moscú", "Moscow" , y "Mockba". Y todos ello son en mismo 'id', es
decir, que si el usuario cambiara su idioma de presentación no solo
deberian cambiar los literales de presentación, sino tambien los
datos. Y, obviamente, no estoy hablando de una sola tabla, sino de
toda la aplicación.
Presentado el problema, ¿hay alguna solución estándar para esto?. O,
a mano, ¿alguna idea mejor que mantener códigos en las tablas
principales que apunten a otra(s) tabla(s) de literales traducidos
para cada idioma?. Porque el mantenimiento de esto se me antoja
bastante complejo y probablemente lento.
Gracias por adelantado!
--
saludos,
jmiguel
http://www.jmiguel.eu
http://www.aerotrastornados.com
Una preguntilla, para animar un poco la tarde del lunes post-puente... :-).
En mi empresa estamos comenzando una aplicacion que tiene como
requisito ser completamente multi-lenguaje. No solo
ingles-castellano-aleman-etc como, tambien Catalán, Euskera y no se
Bable y Andalú.
Para la parte 'de la aplicación' con el soporte nativo de grails creo
que tendremos suficiente, pero el problema se nos plantea por la parte
de datos.
Por poner un ejemplo sencillo, en la 'entidad' (léase tabla, clase de
dominio o como queramos llamarlo) de ciudades tendria que guardar
"Moscú", "Moscow" , y "Mockba". Y todos ello son en mismo 'id', es
decir, que si el usuario cambiara su idioma de presentación no solo
deberian cambiar los literales de presentación, sino tambien los
datos. Y, obviamente, no estoy hablando de una sola tabla, sino de
toda la aplicación.
Presentado el problema, ¿hay alguna solución estándar para esto?. O,
a mano, ¿alguna idea mejor que mantener códigos en las tablas
principales que apunten a otra(s) tabla(s) de literales traducidos
para cada idioma?. Porque el mantenimiento de esto se me antoja
bastante complejo y probablemente lento.
Gracias por adelantado!
--
saludos,
jmiguel
http://www.jmiguel.eu
http://www.aerotrastornados.com
David Santamaria
May 6, 2013, 10:47:36 AM5/6/13
to madri...@googlegroups.com, grailsenc...@googlegroups.com
Hola,
En mi empresa nos encontramos con ese problema hace casi 3 años, y nuestra solución (dogfooding) fue http://grails.org/plugin/i18n-fields
Las limitaciones de esta solución basicamente es que actualmente no utiliza una solución con una tabla de literales como comentas, sino que añade nuevas columnas a la tabla de "dominio" con estos literales (una columna por cada idioma), como te puedes imaginar esto es poco escalable cuando tienes alguna tabla con muchos campos "internacionalizables" y con muchos idiomas.
Estamos trabajando en algo mas escalable, pero igual entre tanto te vale esa solución.
Un saludo.
--
Has recibido este mensaje porque estás suscrito al grupo "MadridGUG: Grupo de Usuarios de Groovy de Madrid" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a madrid-gug+...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a madri...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/madrid-gug?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
David.
jmiguel rodriguez
May 6, 2013, 11:37:59 AM5/6/13
to madri...@googlegroups.com, grailsenc...@googlegroups.com
El día 6 de mayo de 2013 16:47, David Santamaria
<d.high...@gmail.com> escribió:
poco escalable y que me costará convencer a la gente de base de datos
de que el espacio en BD es mas barato que el desarrollo y los ciclos
de cpu :-)
Gracias!
<d.high...@gmail.com> escribió:
> Hola,
> En mi empresa nos encontramos con ese problema hace casi 3 años, y nuestra
> solución (dogfooding) fue http://grails.org/plugin/i18n-fields
Apuntado. Por el lado bueno, que parece bastante simple. Por el malo,
> En mi empresa nos encontramos con ese problema hace casi 3 años, y nuestra
> solución (dogfooding) fue http://grails.org/plugin/i18n-fields
poco escalable y que me costará convencer a la gente de base de datos
de que el espacio en BD es mas barato que el desarrollo y los ciclos
de cpu :-)
Gracias!
Antonio de la Torre
May 6, 2013, 12:21:16 PM5/6/13
to madri...@googlegroups.com, grailsenc...@googlegroups.com
Hola:
Hemos estado viendo internamente cómo lo hemos hecho otras veces y en un proyecto hemos usado también el plugin que comenta David: i18n-fields.
Con exactamente las limitaciones que comentas y además que el findByName ya no funcionaría, salvo que me digáis lo contrario. :-)
Igual se puede eludir este problema con un buen criteria que busque en el campo que corresponda "name_es" según el idioma seleccionado.
Vídeo de la presentación que hicisteis en el Greach de 2011:
Resumen, si no son muchos campos que gestionar, puede ser una solución.
Saludos,
Antonio
--
Twitter: @adelatorrefoss
Twitter: @adelatorrefoss
Iván López
May 7, 2013, 2:15:51 AM5/7/13
to madri...@googlegroups.com, grailsEnCastellano
Hola,
como comenta Toño, en Bokzuy yo utilicé el plugin con buenos resultados. Para las gps's funciona perfecto y es justo lo que necesitas, utilizas objeto.name y en función del idioma el plugin utiliza el campo de base de datos correcto. El problema son los dynamic finders, criterias,... en los que no tienes disponible el campo name, sino name_es, name_en,.... Yo, al tener las chapas multi-idioma, lo que hacía es:
// Esto es un controller
withLocale(new Locale('es')) {
badge = Badge.findByPermalink_esAndIsSystem(params.badge, false, [cache:true])
}
if (!badge) {
withLocale(new Locale('en')) {
badge = Badge.findByPermalink_enAndIsSystem(params.badge, false, [cache:true])
}
}
Esto permite llegar a una chapa así:
Probablemente ese no sea el mejor código, pero ya se sabe, primeros proyectos en Grails y no haces todo lo mejor que debieras, ahora mismo lo haría de una manera completamente distinta y seguramente más limpia.
Yo ya conocía el plugin antes de la charla de Jorge en Greach y después de ésta estuve charlando un rato con él, me comentó alguno de los problemas que habían tenido y también algunas soluciones a futuro que tenían en mente para mejorar el plugin. Por lo que comenta David, todavía no han llegado a esa nueva versión y aunque no escale mucho, parece que les funciona.
Por cierto, si tienes que convencer a los de base de datos de que te dejen hacer bien tu trabajo, tienes un serio problema :-P
Saludos, Iván.
Reply all
Reply to author
Forward
0 new messages