Buenassss: Bueno, he estado pensando y mirando mucho estos días sobre el tema de las traducciones (por ponerle un título). En fin, voy a hacer un resumen. Lo que me molaría es a grandes rasgos: a) que kune se pueda traducir como aplicación de forma fácil (vía web). b) que la gente pueda traducir documentos o contenidos a otros idiomas (tb claro vía web). c) permitir también traducir campos de nuestro repo o bd, que va a ser necesario tarde o temprano. La idea es usar para a/b/c el mismo procedimiento de traducción. Globalize de rails hace bastante fácil a/c y el procedimiento es relativamente sencillo. Adjunto attach de cuando estaba haciendo pruebas con rails, como quedaba la pantalla de traducción. Je je... casi me molaba más el aspecto que tenía antes todo esto... en aquel momento mi duda era que era lo que le faltaba a globalize para permitir traducir del mismo modo documentos. Globalize ya viene con muchas cadenas comunes traducidas (como meses, días de la semana, etc) que podemos reusar. Así que he estado mirando herramientas de traducción de documentos más o menos profesionales, de documentos, de aplicaciones, y como se lo montan. Más allá de que hay formatos estándares para tratar la información, para reusar traducciones ya hechas, para sugerir traducciones, el interfaz de usuario es bastante sencillo. Se divide (segmentación) el documento en partes (segmentos) mediante expresiones regulares (que podemos reusar), y se permite la traducción de cada uno de los segmentos del documento. Una vez traducido se une de nuevo. Una captura de un software web para traducir software libre: http://info.linspire.com/irma/ y otra de un traductor de documentos por segmentos: https://open-language-tools.dev.java.net/editor/screenshot.png para así visualizar lo que estoy comentando. He pensando un repositorio con una propuesta de pinta como esta (las propiedades terminan en -p): repo `-- cms `-- folders |-- documents | |-- group-p # grupo al que pertenece | |-- languageBase-p | |-- permissions-p | |-- segments | | |-- commentToTranslators-p | | |-- originalContent-p | | `-- translations | | |-- contentTranslated-p | | |-- isTheCurrentTranslation-p | | |-- language-p | | `-- needsRevision-p | |-- title-p | `-- user-p # usuario al que pertenece |-- group-p # grupo al que pertenece |-- languageBase-p |-- permissions-p |-- title-p |-- translations | |-- contentTranslated-p | `-- language-p `-- user-p # usuario al que pertenece y que intenta reflejar lo que he visto estos días: que un documento tiene uno o varios segmentos, que de un mismo segmento puedo haber varias traducciones, e incluso varias traducciones en un mismo idioma del cual se elige solo una de ellas (esto se podría simplificar quizá con el versioning), y que algunas traducciones, no están finas todavía. El tema de propietarios/permisos está muy poco pensando, pero lo he puesto igualmente. En realidad, creo que se debería pensar como en Unix y que fichero y directorio, fuera lo mismo, pero vamos, lo he separado por aclarar un poco. Además pienso que el título de ficheros/carpetas debería ser el primer segmento (así también es traducible) pero bueno, lo he dejado así por aclarar. Quedaría así (he quitado folder y he metido la propiedad type): repo `-- cms `-- file |-- languageBase-p |-- segments | |-- originalContent-p | |-- commentToTranslators-p | `-- translations | |-- contentTranslated-p | |-- isTheCurrentTranslation-p | |-- language-p | `-- needsRevision-p |-- type-p # dir o doc |-- permissions-pequipo |-- group-p `-- user-p El uso de directorios ya lo justificaré en otro correo que tengo medio escrito más adelante ;) La idea es crear una estructura de repo, que permita desarrollar estas cosas en el futuro, y no quedarnos muy limitados desde el principio. A lo práctico, los apartados de antes quedarían así: a) Imaginemos un properties de Java, cada propiedad sería un segmento. Con todas las traducciones se generan (con un programa de utilidad) los diferentes properties de cada lenguaje (de GWT o del Server o de lo que sea) y se usa en tiempo de compilación. Muy contado a grosso modo. b) Se crea un documento en un lenguaje determinado, y se salva en segmentos, lo cual no dará curro pero nos permitirá muchas cosas: manejar en un futuro una edición colaborativa y el bloqueo de segmentos no del todo el documento, editar y paginar con comodidad documentos grandes, y a lo que vamos, la traducción por segmentos. Creo que esta estructura permitiría incluso la localización sencilla de imágenes (con textos claro). c) Los campos de BD (o de objetos o como lo queramos ver): Imaginemos que tengo en la bd(o repo) una licencia, y el campo nombre de licencia es traducible "Creative Commons Share-Alike" --> "Creative Commons Comparte por Igual". Pues en la bd/repo, esta en el idioma original (ingles), pero igual con un interceptor (jeje), según el locale de la sesión actual devolvemos la cadena traducida que extraemos del repo, no la versión inglesa. En Globalize de rails, al programar se usaban cadenas del tipo: "Login to collaborate".t y ya con eso, se encargaba de ver en tiempo de ejecución si estaba traducido en la bd para ese locale actual, y si no devolvía la misma cadena en inglés. He estado pensando que se podría hacer algo parecido con GWT, pero no me mola mucho por el momento. Para ello se puede usar ConstantsLookup en vez de Constants y hacer llamadas del tipo: Trans.getString("Login to collaborate"), que o consigue la constante compilada o si no la encuentra intenta acceder o hacer alguna operación en el servidor, mientras devuelve la cadena en ingles (parecido a globalize). Pero bueno, esto no me emociona del todo por ahora. En fin, esto es en lo que estoy pensando ahora. Hay todavía cosas por definir, como los plurales, pero creo que se puede usar la experiencia de globalize y otros proyectos. Creo que una estructura de repo que incluya de alguna forma estas cosas, puede hacer que la parte más usada de kune, la edición/visualización de contenidos sea lo suficientemente potente/útil como para que se use a saco, que era lo que hablábamos hace unas semanas danigb y yo. Por otro lado he preguntando a Antonio por alguna persona que pudiese "liderar" esta parte (la definición y más adelante coordinar los traductores) del grupo del FSM que se encarga de las traducciones (babels). Esto es solo una propuesta muy inicial de como atacar el tema de ficheros/folders y sus traducciones. Con lo que hablemos, meteré el resultado en el wiki para que este correo no se pierda en el limbo de nuestros correos. Abrazos, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Al principio creí que estaba luchando por salvar los árboles. Después pensé que estaba luchando por salvar la selva amazónica. Ahora me doy cuenta de que estoy luchando por la humanidad." [Chico Méndez]
