Traducción de tutoriales en equipo

Tagged: 

This topic contains 7 replies, has 3 voices, and was last updated by  José Miguel 4 years, 3 months ago.

  • Author
    Posts
  • #3415

    José Miguel
    Member

    Hola:

    Entre Gaizka y yo, hemos empezado a traducir a euskera el tutorial de eXe. Acabamos de empezar, pero hay algunas cosas que pueden ser interesantes a los que quieran traducir el tutorial a otro idioma:

    • Hemos utilizado Rainbox para la segmentación y OmegaT para la traducción de cadenas.
    • Estamos utilizando Dropobox, de modo que podemos ir traduciendo cachos cada uno por nuestra cuenta y tenemos actualizados los cambios
    • Hemos utilizado los archivos .po de exe como memoria de traducción, para intentar mantener lo más coherente posible la teminoligía del tutorial respecto a la de la herramienta.

    Cuando terminemos la traducción, publicaremos un tutorial al respecto. Si hay alguien interesado en ir adelantando trabajo, le podemos ayudar a montar una estructura de proyecto análoga.

    ¡Un saludo!

     

  • #3416

    joseramon
    Member

    ¿Alguien os ha dicho que sois unos máquinas? Por si acaso yo os lo digo.

    Yo no me puedo apuntar, ya que sólo controlo el castellano un poco, el andaluz “jaenero” lo domino y pare usted de contar.

    Ánimo y creo que habéis empezado una ruta muy deseable.

    Un abrazo.

  • #3418

    jrfern
    Member

    Maravilloso. Evdentemente la traducción del tutorial a las lenguas del proyecto es una asignatura pendiente, que no me he atrevido ni a mencionar por la falta de recursos (llegamos a la interfaz de usuario y no en todas las lenguas).

    Técnicamente será muy interesante el cómo-se-hizo. Traducir texto, no mensajes de interfaz de usuario, es una tarea totalmente distinta. Un desafío fascinante. Durante segundos he pensado que no conocía dropobox. creo recordar que en su momento hablamos de herramientas colaboratvas y que para la interfaz de usuario únicamente las desaconsejé, quizás sería el momento de darles una oportunidad. ¿Lo habéis pensado? Las memorias de traducción no tienen que ser únicamente los PO del proyecto, puedes incorporar las de gnome o kde… Y para compartir la memoria de traducción de trabajo de OmegaT, ¿se os ha ocurrido algún truco?

     

  • #3419

    José Miguel
    Member

    Hola Juan Rafael:

    En esto de las herramientas de apoyo a la traducción somos principiantes pero, la verdad, nos están gustando mucho. Por ahora, en este tema la delantera la lleva Pablo, que ha traducido de un tirón el tutorial al gallego :)

    Los pasos que hemos seguido son más o menos los de este tutorial: https://dl.dropboxusercontent.com/u/86242384/eXe_learning/es/tutorial_traduccion_moodle/website_index.html

    Lo que hemos hecho es:

    1) Trabajar en una carpeta pública de dropbox, de modo que los miembros del equipo de traducción disponen de todo del proyecto actualizado (incluida la memoria de traducción generada). Como somos pocos y trabajamos en ratos libres, no tenemos problemas de concurrencia. Supongo que con equipos más grandes trabajando fultime, el tema de dropbox puede no ser la solución ideal. De todas maneras, en este tema por meter mucha gente no se mejoran los resultados. Si en el equipo sólo se da permisos a personas “de confianza”, creo que se puede lograr una traducción de calidad. El resultado (incluido el .tmx generado) se puede poner a disposición de quien quiera usarlo para otras traducciones.

    2) Con la herramienta poswap hemos generado un .po es->eu El comando es > $ poswap -i en-es.po -t en-eu.po -o es-eu.po (gracias a Asier Sarasua que nos ha dado la pista). Después, con Rainbow hemos convertido ese .po en un .tmx y lo hemos metido en le proyecto OmegaT como una de las memorias de entrada.

    Con eso, vamos traduciendo en OmegaT las cadenas del los idevices, de los textos alternativos, … Y lo más importante: generamos la memoria de traducción que nos permitirá un mantenimiento ordenado a medida que el tutorial evolucione.

    Todo esto lo documentaremos en un tutorial específico, pero si alguien se anima, le podemos ir generando una estructura análoga.

    Queda un problema pendiente de resolver: los pantallazos están en castellano. Una de las tareas a hacer es generar pantallazos análogos en el idioma destino. Para hacer esto de forma ágil, sería conveniente poder gestionar el catálogo de archivos de eXe de otra manera, ya que la gestión por MD5 no nos ayuda. Interesa poder sustituir los archivos sin ir pinchando idevice a idevice, ya que la traducción es algo que se debe hacer con cada nueva versión del tutorial.

    Este es un tema que seguramente entrará en la próxima hoja de ruta de eXe.

    ¡Un saludo!

    • This reply was modified 4 years, 3 months ago by  José Miguel.
  • #3435

    jrfern
    Member

    Me interesa mucho el proceso. Preguntas e ideas:

    * se me ocurre que a lo mejor estaría más integrado en el proyecto el uso de git para sincronizar versiones que el de dropbox

    * si el tutorial está escrito en html, y se va a traducir con OmegaT (.tmx), ¿para qué pasarlo por PO?

    * si en un proyecto grande preferís trabajar con PO y no xon XLIFF, quizás deberíamos contemplar la exportación y exportación de PO en eXe, además de la actual XLIFF

    * si se pudieran hacer capturas en svg (xml) sería posible utilizar herramientas de traducción directamente sobre ellas

    Saludos

  • #3436

    José Miguel
    Member

    Hola jfern:

    * se me ocurre que a lo mejor estaría más integrado en el proyecto el uso de git para sincronizar versiones que el de dropbox

    La herramienta de sincronización debe ser la que más convenga. A mí montar un git me parece inviable, más que nada por mi desconocimiento. Por otra parte, creo que el usuario medio traductor no tiene conocimientos técnicos suficientes como para manejar un git. Sin ir más lejos, a mí, para hacer unos pocos cambios de código, sólo hacer un push y un pull me ha dado bastantes dolores de cabeza. Con dropbox (o drive, u otro servicio en la nube), este proceso es mucho más sencillo.

    * si el tutorial está escrito en html, y se va a traducir con OmegaT (.tmx), ¿para qué pasarlo por PO?

    Cuando acabemos el proceso de traducción, haremos un tutorial detallado, pero:

    • El tutorial no está en html. Esta en un .elp. La exportación a XLIFF recoge la estructura de nodos, idevices y campos de modo coherente con eXe y así, se puede hacer mejor la labor de importación posterior a la traducción.
    • OmegaT traduce archivos en múltiples formatos (.docx, XLIFF, .html, …), pero además de generar los archivos traducidos, consulta memorias de traducción .tmx externas (generadas en otros proyectos de traducción) y genera memorias de traducción en base a las cadenas traducidas en el proyecto. Esto es crucial para la labor de mantenimiento, ya que, si el tutorial en castellano se modifica, podremos saber qué cadenas están pendientes de traducir.
    • No me he explicado bien con el .po. Lo que hacemos es tomar los .po creados a la hora de traducir la herramienta y generar un .tmx de entrada para que si en el tutorial tenemos que traducir la cadena “Actividad de lectura”, lo hagamos igual que en la herramienta.

    * si en un proyecto grande preferís trabajar con PO y no xon XLIFF, quizás deberíamos contemplar la exportación y exportación de PO en eXe, además de la actual XLIFF

    El formato XLIFF es más adecuado para traducir contenidos, ya que trata mejor problemáticas asociadas a los formatos (etiquetas, textos alternativos a imágenes, , segmentación, …). Para eso se generó ese estándar y estoy seguro de que es la vía correcta.

    * si se pudieran hacer capturas en svg (xml) sería posible utilizar herramientas de traducción directamente sobre ellas

    Lo desconozco. De todos modos, por cada imagen terminaríamos teniendo uno archivo en castellano y otro en euskera. Al ser archivos con MD5 diferente, nos encontramos con problemas de gestión de archivos en eXe que, desde mi punto de vista, conviene abordar.

    ¡Un saludo!

    • This reply was modified 4 years, 3 months ago by  José Miguel.
  • #3444

    jrfern
    Member

    Estamos aclarando malentendidos.

    >  A mí montar un git me parece inviable

    Me refería a usar la infraestructura ya disponible. Creo que aprotarái cosas sobre dropbox (mejoras en bloqueo de usuarios y control de versiones, versiones propias…). A cambio, mayor exigencia inicial, claro.

    > Esta en un .elp. La exportación a XLIFF…

    Eso es lo que no había entendido – creía que trabajábais sobre la exportación html pasándola a PO. Entonces el ciclo es .elp -> XLIFF -> tmx, y el PO es para engordar  la memoria de traducción. Entendido.

     

  • #3450

    José Miguel
    Member

    Hola Juan Rafael:

    Leyendo mi mensaje de la mañana, veo que ha quedado muy rotundo. Cosas de escribir a prisa y corriendo mientras se hacen las copias de seguridad. 😀

    Seguro que a medida que el equipo de traductores crece y el número de tutoriales a traducir aumenta, es necesario utilizar herramientas de control de versiones más profesinales como git. Para echar a andar, empezaremos con dropbox y os contamos a ver qué tal.

    ¡Un saludo maestro!

You must be logged in to reply to this topic.