[kune-devel] Traducción de kune, de documentos y propuesta de organización

[Vicente J. Ruiz Jurado]

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]




------------ próxima parte ------------
Se ha borrado un mensaje que no est? en formato texto plano...
Nombre     : Pantallazo-kune home - Mozilla Firefox-1.png
Tipo       : image/png
Tama?o     : 47468 bytes
Descripci?n: no disponible
Url        : /pipermail/kune-devel/attachments/20070627/7186c264/Pantallazo-kunehome-MozillaFirefox-1-0001.png