[kune-devel] Posibles soluciones para el tema de la internacionalización de kune

Sat Nov 10 19:19:51 CET 2007

Muy buenas:

Escribo a la lista para darle un poco de vidilla y porque con las
conversaciones 1-1, al final, no es tan enriquecedor.

Un resumen de lo que he estado mirando. Se me ocurren tres opciones
(aunque también se puede elegir una combinación de estas):

1) User constantes y mensajes (opción estándar de GWT)
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Internationalization.StaticStringInternationalization.html
- Genera por cada locale código html en tiempo de compilación
- Si se cambia el locale desde el GUI, hay que hacer toda un "refresh"
completo en el cliente (carga diferentes .html/.xml)
- En principio, si se cambia un .properties de un locale (solo), la
compilación no se entera y no actualiza (por lo menos con gwt 1.4.60),
pero estaría bien que solo compilara los ficheros que precisa.
En definitiva requiere una compilación completa para cualquier
modificación en las traducciones.
- Usas métodos tipo miClase.AreYouSure();
Ventajas: se optimiza en tiempo de compilación para descartar cadenas no
usadas en el código, detectar errores, etc.

2) Diccionario (segunda propuesta de GWT)
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Internationalization.DynamicStringInternationalization.html
- Generar un .js por cada locale (también se podría generar un solo js,
con todos los diccionarios, pero cargarías todos los idiomas para cada
cliente lo cual no tiene mucho sentido).
- Todo en tiempo de ejecución
- Propenso a fallos si falta alguna clave
- Se manda todo incluso si no se usa
- Adecuado para aplicaciones ya internacionalizadas
- Al final, es similar a tener un hashMap, aunque más limitado. De hecho
cuando cargas un diccionario, obtienes una especie de hashMap.

3) Generar servicio RPC para i18n propio (opción propia "casera", aunque
ya hay gente opta por esta opción según leí en algún hilo).
Si no nos gusta la opción 1) por los rollos de compilación y ya que la
opción 2) en la práctica es bastante floja, creo que es más interesante
generar una funcionalidad propia que básicamente recuperar del servidor
un hashMap con todas las cadenas necesarias para un locale determinado.
Tendríamos una llamada RPC inicial tipo:

map = servicioI18n.getLocale("es");

y luego podríamos tener llamadas del tipo (a lo Globalize):

t("Are you sure?")

que buscaría esa cadena en el HashMap. También podríamos generar métodos
tipo:

public String AreYouSure() {
  return map.get("Are you sure?");
}

si nos parece más elegante, pero no se si vale la pena. Siempre me ha
gustado lo fácil que se internacionaliza con Globalize en rails.

El hashMap lo podemos generar a partir de los datos de una tabla de bd.
Si en un idioma determinado, no está traducido, se envía el del idioma
por defecto.

También se podría recuperar diferentes hashMaps por, por ejemplo,
módulo, para no tenerlo todo en el servidor junto:

chatMap = servicioI18n.getLocale("es", "ChatModule");

Inconvenientes de la opción 3): menos óptimo que la opción 1), un poco
más de curro que la 1) ya que hay que generar ciertas clases y cierto
modelo (aunque se puede fusilar de Globalize).
Ventajas: más dinámico que la opción 1) ya que no requiere de
compilaciones (con actualizar la fuente de datos basta), funcionalidad y
prestaciones similares al diccionario 2), pero con la ventaja que
podemos extender la clase para dar más funcionalidad sin estar atados al
parseo de un simple fichero javascript. La misma funcionalidad se puede
usar a nivel de servidor para los mensajes que se tendrán que generar
para el cliente más allá de gwt (notificaciones por correo, parte
pública estática, etc). Internacionalizar nuestro código actual sería
sencillo (añadir el método Trans.t("Cadena") a las "Cadena" ya
existentes). Más cómodo a la hora de programar (los .properties, es un
coñazo).

Entonces yo me decantaría por seguir con 1) en el cliente (aunque en el
servidor se necesitaría algo adicional) o pasar directamente a usar la
2) que es la que me parece da más juego tanto en el cliente como en el
servidor.

¿Se me escapa algo? Dani, ¿qué te parece? Seguro que sacas a relucir
cosas que yo no veo.

Abrazotes,

-- 
Vicente J. Ruiz Jurado

http://homes.ourproject.org/~vjrj/blog
http://ourproject.org

 "Lo que ha sido creído por todos siempre y en todas partes tiene todas
 las probabilidades de ser falso." [Paul Valéry]