Algo más que traducir
Blog sobre traducción profesional, localización de videojuegos, software, aplicaciones móviles, sitios web y tecnologías de la traducción por Pablo MuñozTraductor inglés-español especializado en localización

Excel como herramienta para traducir videojuegos

Logotipo de ExcelEl otro día descubrí el blog Analizando la traducción gracias a una entrada muy interesante titulada Localización de videojuegos: ¿alternativas a Excel?. Aunque respondí en un comentario, el tema me ha parecido tan bueno que he creído conveniente escribir una entrada para expresar mi opinión con más detalle.

Si de por sí la localización de videojuegos está poco investigada, peor es la situación de las herramientas informáticas aplicadas a la localización de videojuegos. En algunos artículos he leído que en este tipo de traducción, como en la mayoría, se usan herramientas de traducción asistida y memorias de traducción. Sin embargo, por mi experiencia y la de varios amigos que trabajan en el sector, la verdad es algo bastante poco frecuente.

La norma es usar Excel nos guste o no, aunque lo cierto es que no sé por qué se decidió usar este programa, aunque supongo que es porque Excel es muy popular entre las aplicaciones ofimáticas y porque para el desarrollador es fácil exportar e importar texto gracias a estos archivos.

¿Es Excel un programa poco eficaz para la localización de videojuegos?

Sí y no: todo depende de las características del proyecto. Por ejemplo, he trabajado en proyectos donde había 30 archivos, uno por cada capítulo del juego, y cuya estructura estaba muy bien definida. Además, contenía una macro rápida y fiable que contaba los píxeles del texto de la caja. En resumen, que trabajaba cómodamente con el archivo y me ayudaba a ser productivo.

Sin embargo, no siempre es todo tan bonito. Otras veces me ha tocado lidiar con demasiados archivos que encima contenían una o dos frases. Esto es mucho más incómodo para ser productivo, porque cuesta mucho más gestionar tantos archivos con una estructura deficiente. Ahora bien, yo creo que esto es más un problema de diseño de los archivos que otra cosa.

¡Pero si no trabaja con memorias de traducción!

Totalmente cierto, y eso puede llegar a ser un gran hándicap en según que casos. No obstante, en la gran mayoría de los juegos en los que he trabajado, no me he encontrado con textos repetitivos e, incluso así, intentaba darle un toque diferente para que no fuera igual. No hay que olvidar que traducimos un videojuego, no un manual, y que las repeticiones son normalmente escasas.

Ahora bien, si trabajamos en un juego muy grande, es muy posible que nos sea útil usar una memoria de traducción, por lo que usar Excel únicamente para traducir puede a suponer un gran problema de cara a nuestra productividad.

Entonces… ¿por qué se sigue usando Excel?

Porque, a diferencia de un documento de Word o Adobe InDesign, no hay estándares que definan la estructura de un archivo de localización de videojuegos. En consecuencia, cada desarrollador se las apaña como puede para crear archivos de Excel con los que sea fácil trabajar… para ellos. Porque esa es la segunda razón: los desarrolladores no son traductores y, por tanto, no siempre comprenden las verdaderas necesidades de un traductor.

Por tanto, ellos creen que basta con una macro que cuente los píxeles y poco más. Y sí, es cierto que eso es “suficiente”, pero… ¿dónde están las herramientas de terminología? ¿Dónde están las herramientas de análisis del número de palabras por columna en varios archivos para que no tengas que copiar y pegar una columna a Word, archivo por archivo? Por no hablar de que, cuando se trabaja con muchas etiquetas, resultaría muy útil ver una vista previa del texto en pantalla o algo similar y así ajustar la a veces importante alineación del texto.

¿Hacer herramientas mejores, e implantarlas, es una utopía?

Como todo, cambiar el esquema actual y ponerse a desarrollar herramientas adecuadas lleva tiempo, esfuerzo y dinero. Yo en su día hice un editor diseñado exclusivamente para traducir los textos de un juego (abajo tenéis la imagen) y lo cierto es que era muy fácil personalizarlo a través de código.

Editor de diálogos del Phantasy Star II

Y si le echáis un vistazo a la captura de ACME, el programa que ha preparado SoyWiz es simplemente genial. Dicho de otro modo, yo creo que sí es posible, aunque no fácil, hacer herramientas mejores y acabar implantándolas, aunque para ello va a haber que luchar mucho.

Por ahora existe una herramienta de traducción asistida más que interesante y compatible con Excel llamada Felix que suple las carencias de memoria de traducción y glosarios. Yo creo que es un paso interesante para optimizar el trabajo de los traductores, aunque su funcionamiento es algo engorroso.

La verdad es que, con tiempo y ganas, creo que podría hacer alguna aplicación como Felix, aunque no tengo muy claro cómo lograría hacer lo de la memoria de traducción. Pero vamos, hice una prueba para crear una ventanita que detectaba si en la celda en la que estabas había un término de glosario y te lo marcaba, así que… ¡todo es posible!

Curso online de Excel para traductores, revisores y gestores de proyectos

No te imaginas la de cosas que se pueden en hacer en Excel que son relevantes para nuestro trabajo. Por ello, he creado un curso online en Traduversia sobre Excel, así que si te invito a que le eches un vistazo. 😉

Excel para traductores, revisores y gestores de proyectos

Excel para traductores, revisores y gestores de proyectos

¡Comparte esta entrada! 🙂
Share on Facebook
Facebook
0Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin
Pablo Muñoz Sánchez

Pablo Muñoz Sánchez

English > Spanish Game Translator
Soy traductor inglés > español con más de 15 años de experiencia especializado en localización de videojuegos y software. He traducido juegos como Metroid y Fire Emblem y ahora trabajo, entre otras cosas, como especialista en control de calidad para Google a través de Vistatec. También soy cofundador de Traduversia, una plataforma de cursos online para traductores. Más sobre mí | Mi libro de localización | Mi Instagram

¡Apúntate GRATIS al curso online «Localización y traducción audiovisual: primeros pasos y trucos ninja» de Traduversia!

Localización y traducción audiovisual: primeros pasos y trucos ninja

31 comentarios

  1. Pablo, muy interesante la entrada. No estoy muy puesto en el tema pero creo que xliff es un estándar que podría aplicarse como formato en la traducción de videojuegos, es compatible con Excel (por ser XML) y que puede cargarse en herramientas CAT. ¿Cómo lo ves?

  2. Trados antiguamente tenía un componente llamado T-Window que hacía lo mismo que Felix: conectarse con Excel y Powerpoint, entre otros. SDLx tenía SDL Clipboard que traducía lo que estaba en el portapapeles. Herramientas útiles para superar unas limitaciones que no deberían estar ahí.
    Quizá los desarrolladores de videojuegos deberían aprender un poco de las prácticas de los desarrolladores de software, cuyo proceso de localización da muchos menos quebraderos de cabeza, en parte porque no tienen el medio audiovisual del que preocuparse.

    Olli: XLIFF es un estándar potente y flexible para almacenar texto traducible, pero luego muchos desarrolladores prefieren trabajar con PO, que es un formato arcaico y muy limitado, pero con el que están más cómodos. Una vez más, nadie piensa en nosotros, pobrecitos traductores. Además, cada desarrollador hace las cosas a su manera, por lo que la conversión a XLIFF puede ser casi artesanal al variar tanto con cada juego.

  3. Hola, Pablo,

    Te leo desde hace mucho, aunque es la primera vez que me animo a poner un comentario.

    Aunque no he tenido oportunidad de traducir videojuegos todavía, creo que Excel no es el programa ideal para la traducción, ya que no ha sido diseñado para esa función, y menos para escribir o redactar, sino para realizar cálculos y operaciones matemáticas o, en menor medida, bases de datos.

    A mí me parece que un programa como el ACME que citas con alguna función añadida, que manejara archivos XLIFF y que permitiera importar y exportar cadenas de texto tan fácilmente como Excel (que creo que es una de las razones por las que tanto se utiliza en este mundillo), sería la repanocha. Yo soy de los que piensa que cada aplicación debería utilizarse para el fin con el que fue creada, aunque, claro, no siempre somos nosotros los que decidimos con qué herramientas trabajar.

  4. Pablo Gismero dice:

    Buenas, tocayo:

    Quien te haya dicho lo de las memorias de traducción en el campo de la localización de videojuegos… Muy, pero que muy pocas veces he visto extendida esta práctica, y las veces que he tenido que usar MT han sido escasas, amén de que no aportaban demasiado en la gran mayoría de los casos, sino lo contrario: tenías que descartar en muchas ocasiones gran número de entradas que no venían a cuento. ¿Por qué? Por ejemplo, porque el cliente te mandaba una MT que había usado tanto para un Mortal Kombat como para un RPG. Sí, una chapuza…

    Donde sí es imprescindible el uso de una MT es en un MMORPG, que fácilmente va más allá del medio millón de palabras, y donde la terminología es imprescindible, puesto que siempre hay varios traductores. Eso sí, tienes que tener a una persona encargándose exclusivamente del mantenimiento de los glosarios y la MT, porque después pasan las cosas que pasan: la MT puede tener incoherencias, faltas de ortografía…

    Para el último juego que estoy traduciendo me han dado acceso a una nueva herramienta de traducción online; al principio era un suplicio, porque hacía agua por todos lados, pero ahora está algo mejor. Aun así, no me gustan las herramientas online, puesto que dependen demasiado de la conexión, y en muchas ocasiones tarda cierto tiempo en cargar la siguiente traducción. Uno o dos segundos no parecerán demasiado, pero se nota muchísimo a la larga.

    Como bien dices, añadir unas pocas funciones a un excel y proporcionarle una interfaz de usuario fácil de usar sería magnífico. Pero para eso ya está el SDLX, ¿no? De los programas de traducción asistida que utilicé en el máster de la UJI es el que más se parecía a un excel, por el formato de celdas y columnas que tiene, y Fran me ha dicho que lo usa bastante para sus traducciones. Yo me he vuelto un perezoso de cuidado y casi prefiero optar por la comodidad del excel, pero sí es verdad que me gustaría hacerme una MT con todas mis traducciones, porque muchas veces te aparece un término que sabes que has traducido, pero que no recuerdas.

    Un saludo.

  5. Pablo Gismero dice:

    Por cierto, acabo de ver el tal programa ACME y me ha parecido una maravilla, aunque le falte alguna función que otra para exportar e importar, pero es una buena idea, y la interfaz es muy agradable y parece fácil de usar. Ya podría la Gran N hacer algo así…

  6. ultrasonica dice:

    Muy buena entrada. Quería preguntarte algo con respecto a lo que comentas de los “píxeles de texto”. Una vez leí que en los subtítulos de los videojuegos la extensión del texto traducido no se mide en caracteres como en la traducción audiovisual sino en píxels, ¿podrías aclararme esta duda?
    Muchas gracias y enhorabuena por tu blog.

  7. Hola a todos:

    Gracias por vuestras opiniones, os contesto uno a uno 🙂

    @Olli: Tienes razón en que el XLIFF es un formato mucho más flexible y está estandarizado, pero no sé qué tal se comportaría en localización de videojuegos, al haber muchos saltos de línea manuales que no suele haber en el resto de traducciones. Pero bueno, al menos se estaría usando un estándar 🙂

    @Jordi: Pues no tenía ni idea de que se podía hacer eso con Trados. Me suena haber visto ese complemento, pero no llegué a trastear demasiado. ¡Gracias por mencionarlo! 🙂

    Y sí, no estaría mal que los desarrolladores de videojuegos aprendieran cosillas de los desarrolladores de software. Por ejemplo, si no me equivoco, Nokia usa Passolo para traducir las interfaces de móviles, incluso con una función que indica los caracteres máximos por línea. ¿Alguien podría confirmarlo?

    José Manuel: Gracias por haberte animado a comentar. Acabo de echarle un vistazo a tu blog y está muy bien, ahora te añado un enlace 🙂

    La verdad es que ahora que lo dices, y sumado a la idea de Olli, un primer paso interesante sería que el supuesto programa parecido a ACME fuera compatible con XLIFF (o al menos XML básico). Así, aunque luego salgan otros programas, al menos los archivos serían compatibles con todas las aplicaciones.

    Entre todos estamos dando buenas ideas con las que empezar a crear un programa decente 🙂

    Pablo Gismero: Pues créeme que he oído eso de que se usan memorias de traducción en videojuegos 🙂

    A mí SDLX me gusta mucho, lo he usado alguna vez y creo que es un entorno muy cómodo y útil para traducir. Y sí, al fin y al cabo, la interfaz no es muy diferente a la de Excel…

    Comparto tu preocupación sobre las herramientas en línea. A mí me ha tocado trabajar así dos veces y es bastante engorroso, la verdad. Creo que aún tienen que pasar unos cuantos años para que las conexiones vayan rápidas y este tipo de programas no vayan tan lentos y sean cómodos de usar.

    Y sí, seguro que con los cerebritos que hay en Nintendo, en dos días hacen un programa como ese 🙂

  8. Hola ultrasonica:

    Bueno, realmente en videojuegos no hay subtítulos a menos que haya audio subtitulado, en cuyo caso funciona igual que en la traducción audiovisual, es decir, por caracteres.

    Lo de que la limitación en videojuegos venga dada por píxeles se debe a que normalmente la fuente es de ancho variable. De este modo, se tiene en cuenta el grosor de cada carácter para aprovechar mejor el espacio. Y si va por caracteres, es porque seguramente el ancho de cada letra es el mismo o que el desarrollador no ha querido hacer las cosas mejor para hacer un cálculo más aproximado del espacio disponible en una caja de texto, lo que cual puede tener sorpresas desagradables tras implementar el texto en el juego.

  9. Hola, Pablo:

    Me ha hecho muchísima ilusión que la reflexión que hice en mi blog sobre el Excel te haya dado tema para hacer tú una entrada.

    Lo único que me gustaría añadir, y que ya he comentado en mi blog, es que lo que realmente hace falta es que los traductores de videojuegos luchéis desde dentro. El cambio no va a llegar de la mano de los desarrolladores, porque a ellos ya les va bien como está.

    Me gusta pensar que si todos “sugirierais” a vuestras respectivas empresas que os hace falta un programa para ser más productivos, quizás tendríais suerte y se investigaría este campo. Mientras no digáis nada, nada va a cambir.

    ¡Un saludo!

  10. Hola Pablo,

    Cuando empecé en este mundillo de la localización de videojuegos hace unos 5 años, me llevé las manos a la cabeza cuando me enteré de que utilizaban Excel para traducir (sobre todo viniendo de una compañía como SDL International). Al cabo de unos meses empecé a comprender por qué…

    Excel, aunque no sea una herramienta idónea para la traducción, es una herramienta estándar que todos los traductores saben cómo utilizar, y cualquier programador principiante puede crear una herramienta básica para exportar a e importar de Excel.

    En la localización de videojuegos casi nunca resulta necesario reutilizar traducciones de un proyecto a otro, por lo tanto la mayor ventaja de las aplicaciones de memoria de traducción desaparece.

    Con Excel el equipo de desarrollo no necesita invertir en ninguna herramienta de traducción, ya sea, adquiriendo una existente o creando una nueva, ni en formar a los traductores.

    Por otro lado, el traductor es libre de utilizar la herramienta de traducción que quiera por su cuenta. Las principales herramientas de traducción de hoy en día te permiten crear proyectos de traducción a partir de archivos Excel. Está claro que hay un poco de trabajo manual para preparar los archivos, pero si realmente vieran la necesidad de hacerlo para un proyecto específico, lo pueden hacer.

    Excel 2007 también ha mejorado mucho con respecto a la versión 2003. En la versión 2003, por ejemplo, había muchos problemas con la cantidad de texto y de líneas que se podían utilizar en una celda. Con la versión 2007 también se pueden filtrar y ordenar las filas muy fácilmente.

    En fin, entiendo la frustración de algunos traductores, pero yo creo que el problema no es Excel, ni el hecho de que no se utilice una herramienta de traducción, sino el formato de los archivos Excel que utilizan ciertos equipos de desarrollo. Lo importante es que el equipo de desarrollo conozca las necesidades de los traductores y que los archivos Excel se generen teniendo esto en cuenta. Como ejemplos:

    – El archivo Excel solo debería contener las columnas necesarias; el traductor no tendría que invertir media hora cambiando la anchura de ciertas columnas y ocultando otras.

    – Lo ideal es que solo haya un archivo Excel, con un número mínimo de hojas (3 o 4 como mucho); esto facilita muchísimo la búsqueda de texto y reduce la posibilidad de que a un traductor se le olvide traducir alguna de las actualizaciones.

    – Las actualizaciones en el texto inglés deberían estar resaltadas de forma clara; el traductor debería poder ver rápidamente lo que ha cambiado en el texto inglés en vez de tener que buscar durante 5 minutos lo que ha cambiado en una celda con un párrafo completo de texto.

    – Si se añaden macros de longitud de texto al archivo Excel, éstas deberían utilizar píxeles en lugar de caracteres, ya que el límite real es casi siempre un número máximo de píxeles y no de caracteres. La macro debería impedir que el traductor introduzca traducciones demasiado largas.

    – La herramienta que exporta a Excel debería “pretraducir” strings nuevas cuyo texto ya se ha traducido en otra parte del archivo. No para que el equipo de desarrollo se ahorre unas céntimos, ya que el traductor debería revisar estas pretraducciones, sino para aumentar la coherencia. Esto sería equivalente a la capacidad de traducir los 100% matches de una aplicación de memoria de traducción.

    – La integración de las traducciones debería ser automática. El traductor no tendría que preocuparse de resaltar todo lo que ha cambiado en el archivo Excel, ni tener que asegurarse de que el equipo de desarrollo integró bien las traducciones enviadas en la versión anterior del archivo.

    En definitiva, yo creo que Excel puede ser una herramienta muy completa y potente de traducción, pero el equipo de desarrollo tiene que saber cómo utilizarla para facilitarle el trabajo de traducción a los traductores.

    Un saludo,

    Adolfo

  11. ¡Hola a todos!

    Me he sentido un poco bicho raro leyéndoos, porque debo ser aquí la única que traduce videojuegos con memorias de traducción. Las empresas de localización de videojuegos españolas con las que trabajo utilizan Trados o SDLX en casi todos los proyectos.

    Aunque los desarrolladores utilicen Excel para volcar el texto, los intermediarios, ya sea una multinacional de la localización o la editora que coordina la localización multilingüe, son las que deciden o se ocupan normalmente de organizar el proceso y las herramientas que se utilizan. Por lo que en realidad son éstas las que deberían idear, diseñar e invertir en la creación de una herramienta específica de su sector.

    El traductor autónomo que está en su casa, podrá decir “yo opino que…” pero son las empresas de localización las que tienen la sartén por el mango y pueden decirle al desarollador y a la editora cómo mejorar el proceso, aumentar la calidad, reducir costes, etc. utilizando o creando las herramientas adecuadas.

    También he trabajado con algunas herramientas creadas por una editora o un desarrollador para un juego concreto y no han resultado del todo cómodas para el traductor en comparación con un archivo de word y una memoria de traducción.

    Y ya que mencionas a los cerebritos de Nintendo, creo que es una empresa con el perfil perfecto para crear la herramienta ideal. Porque si se encargan de todas las fases de producción de un juego, ¿quién mejor que ellos para mejorar la forma de trabajo y el rendimiento de sus traductores y revisores en plantilla?

    Por último añadir que SDLX me ha resultado muy cómo para trabajar siempre que lo he usado y lo mejor es lo de poder usar varias memorias y varios glosarios. Además de no tener los problemas de formatos y códigos que se tienen con Trados. De todos modos, creo que la nueva suite de SDL Studio es más parecida a SDLX que a Trados y puede estar bien, aunque todavía no he trabajado con ella.

  12. Adolfo, has publicado tu mensaje mientras yo escribía el mío y lo he leído después.

    Me ha parecido tan interesante lo que contabas que he visitado tu web y después de leer tu CV creo que eres el candidato ideal para crear la herramienta soñada por todos los traductores de videojuegos aquí presentes 😉 ¡Un traductor reconvertido en ingeniero de localización que trabaja para una desarrolladora/editora!

    ¿Votos a favor de que Adolfo desarrolle la aplicación?

    Por cierto, los ex-alumnos de la FTI-UGR somos como una plaga, cada día descubro a un nuevo por el ciberespacio.

  13. Pablo Gismero dice:

    Hola, Dalia:

    Como he dicho antes, me he encontrado con algunas empresas que te mandaban memorias de traducción “generales”, como si fuera una especie de cajón de-sastre, y a mí me terminaba por molestar bastante a la hora de traducir, empezando por el hecho de que, de vez en cuando, traduces para una u otra plataforma, y tenías que estar borrando concordancias del 99 o 100% que, realmente, no te servían en ese caso. Y también hay que emplear mucho tiempo para tener bien limpias y cuidadas las memorias, aunque quiero suponer que para eso hay traductores encargados de tal tarea en las empresas de localización de videojuegos.

    De todas formas, si los glosarios y las memorias que te envía el cliente son buenas, mejor trabajo quedará, sobre todo en el caso de sagas (bueno, esto es algo, más bien, imprescindible).

    Como bien dice Dalia, los traductores autónomos podemos opinar, pero es más bien la compañía de localización la que tiene que aleccionar a los desarrolladores.

    Un saludo.

  14. Hola a todos 🙂

    En primer lugar me agradecer a Pablo la mención de mi herramienta.

    En segundo lugar me gustaría justificar un poco el hecho de trabajar en la nube:

    Por una parte trabajar en Internet permite a varias personas traducir sobre lo que originalmente podría ser un mismo archivo. Con un excel (a no ser que se use el google docs) diría que esto no se puede (al menos con las versiones que yo he trabajado). También permite que las personas involucradas en el proyecto, no tengan que estar físicamente en el mismo lugar. En empresas de traducción donde los trabajadores estén físicamente en unas oficinas, esto no es un problema. Pero si hay varios traductores freelance en un mismo proyecto, sería de gran ayuda.

    Permite la creación automática de feeds RSS para seguir los cambios que se hacen:
    http://picasaweb.google.com/soywiz/Portfolio#5463269587668753074
    Útil para revisores o para seguir la progresión de la traducción cuando los traductores no están físicamente en el mismo sitio.

    La traducción está siempre disponible. Los backups son transparentes y te olvidas de ellos. Si se te estropea el ordenador, puedes ir a cualquier ordenador y seguir traduciendo.

    Igual que con otras herramientas (que no sean el excel) sabes en todo momento los textos que hay traducidos, los que faltan por traducir, y en el caso de los revisores los que han sido revisados y los que no.

    Los glosarios no deberían suponer ningún problema en una herramienta online. Se almacenan en la nube y ya está.

    Respecto a la preocupación de la velocidad de las conexiones y la conectividad… El tema de la velocidad de las conexiones no lo veo un grave problema.
    El ACME original era algo lento al respecto, pero conforme han ido pasando los años han empezado a surgir tecnologías que hacen que todo pueda ir más rápido. Usando Javascript+HTML5, se pueden cargar los datos en segundo plano sin mucho problema.
    Respecto a la conectividad, en Firefox, en Chrome y en Internet Explorer con un plugin de google llamado Google Gears, una página web puede trabajar offline. Detectar cuando hay conectividad a Internet y tener una base de datos local donde guardar los cambios hasta que vuelva a haber conexión 🙂 Vamos que estas cosas están ya más que superadas.

    El Excel permite la importación y exportación de hojas en formato XML y CSV. No debería ser extremadamente complicado hacer importadores y exportadores.

    Con Javascript además se pueden montar fácilmente “plugins” para determinar el ancho en pixeles en fuentes de ancho variable. Además de que no hay problemas en tener todo tipo de estadísticas: número de palabras por línea, número de líneas, número de caracteres… Y producir advertencias visuales cuando se superen los límites globales o los establecidos para un bloque en concreto.

    ¡Saludos!

  15. Sobre lo que ha dicho Adolfo, que casi nunca se pueden reutilizar traducciones de un proyecto a otro, no sé yo si es del todo cierto (¡ojo, que hablo sin saber! Quizás lo que comento más abajo ya existe, no sé…).

    Hay traducciones que están estandarizadas, como por ejemplo las advertencias en los manuales del juego, o “no apagues la consola mientras…”, y ese tipo de mensajes comunes a todos los juegos. Por lo tanto, una memoria sí que ahorraría algo de faena, aunque también es cierto que no es una cantidad de trabajo exagerada.

    Por otra parte, creo que las empresas podrían crear buenas memorias de “sagas”, donde se suele compartir terminología de un juego a otro. Me vienen a la cabeza ejemplos como Final Fantasy, World of Warcraft, Silent Hill, Metal Gear Solid, etc… Esto de crear sagas, o distintas versiones de juegos muy parecidos (Grand Theft Auto, Imagina ser…), es algo realmente común últimamente. Por lo tanto, contar con una memoria de la “saga” supondría menos trabajo de buscar y documentarse.

    Vamos, resumiendo: como ya he dicho, creo que un buen programa, pensado tanto para traductores como para desarrolladores, os haría ser mucho más productivos, e incluso me atrevo a decir que la calidad de la localización aumentaría y que llevaría menos tiempo.

  16. Bueno, ya veo que esto está bastante animado. 🙂 ¡Gracias por vuestras aportaciones!

    @Ana: Gracias a ti por escribir tu entrada, ya que me serviste de inspiración. Sobre lo de luchar desde dentro, créeme que no he sido el único que ha luchado sin éxito…

    Respecto a tu último comentario, bueno, yo pienso que sabiendo que ese tipo de mensajes son oficiales y que un error en ellos puede suponer no pasar el testeo final y retrasar el proyecto, el desarrollador debería pegarlos tal cual de los glosarios oficiales. Pero bueno, para “traducir” ese tipo de mensajes se hace un “copipega” y listo. Si ese fuera el único uso de las memorias de traducción para la localización de videojuegos, creo que no harían tanta falta 🙂

    @Adolfo: Desde luego, se nota que tienes mucha experiencia en esto, y tu comentario realmente aporta muchísimo.

    Efectivamente, como mencionaba en la entrada, a veces es más importante que el diseño del archivo esté bien hecho más que otra cosa. En el caso que mencionaba, donde tenía un archivo por capítulo de juego, todo estaba superclarito y no hacía falta marcar los cambios, porque el desarrollador implementaba todo con un par de clics (bueno, no lo sé exactamente, pero es la impresión que me daba).

    Aunque es posible preparar los archivos de Excel para trabajar con programas como Trados, ¿qué haces cuando hay macros para contar los píxeles? Ahí es donde veo el principal problema.

    Respecto a lo de las actualizaciones del inglés, totalmente de acuerdo. Anda que no ha habido veces que hemos tenido que usar herramientas externas de comparación porque ni nos marcaban los cambios…

    En fin, como dice Dalia, habiendo estudiado informática eres un candidato idóneo para crear la herramienta definitiva. 🙂

    @Dalia: Tienes razón en que las agencias deberían preocuparse del “trabajo sucio” y mandar archivos bien preparados o incluso crear una herramienta adecuada. La verdad es que no sé cómo es posible que SDL todavía no haya hecho nada al respecto… En fin, veremos a ver cómo se desarrolla todo con el paso del tiempo gracias a la popularidad que va adquiriendo poco a poco la localización de videojuegos.

    @Carlos: Me alegro de verte por aquí y que hayas detallado tu opinión de Excel comparado con tu ACME. 🙂 Tengo una pregunta: ¿qué tal la seguridad? Porque si a Nintendo le dices que tienes sus archivos en Internet, se pueden echar las manos a la cabeza. ¿Se podría crear algo así a nivel interno?

    ¡Interesante debate, interesante!

  17. Hola de nuevo, Pablo:

    Ya sé que la pregunta sobre el ACME y la seguridad iba para Carlos, pero me ha hecho plantearme una duda: las empresas grandes como Nintendo o Square-Enix (al igual que las empresas de localización en general), ¿no cuentan con una intranet?

    No sé, yo creía que tendrían algún sistema interno para comunicarse y que no se pudiera piratear desde el exterior.

    En caso de que sea así, entonces usar un ACME no sería ningún problema en cuanto a seguridad se refiere, ¿verdad?

  18. Hola Ana:

    Mmm… Pues sí, tienes razón, no debería haber problema en instalar esa solución de forma “local”, ya que también tenemos programas parecidos para usarlos con el navegador… Mientras se usen los servidores de Nintendo, no debería haber demasiados problemas.

    ¡Gracias! 🙂

  19. El principal problema con la creación de una herramienta de traducción “global” es que tiene que poder leer muchos tipos de archivos. El formato de los archivos de localización varía de un proyecto a otro. De hecho suele depender del motor del juego. Algunas compañías supongo que habrán conseguido implantar un estándar para que todos sus juegos utilicen el mismo formato de archivo, pero esto no es fácil, sobre todo si se utilizan motores diferentes y se programa para varias plataformas.

    Cuando hablo de los archivos de localización, no me refiero a los archivos Excel. Excel es la interfaz para los traductores, pero el juego no lee estos archivos Excel, sino que el desarrollador crea una herramienta para exportar a e importar de Excel. Esta herramienta exporta transfiriendo el contenido traducible a Excel e importa actualizando los archivos que lee el juego con las traducciones de los archivos Excel.

    Lo que realmente sería interesante sería que todos los desarrolladores de motores de juegos se pusieran de acuerdo y utilizaran los mismos tipos de archivo de localización. Microsoft y Sony han hecho algo parecido con los archivos que contienen las traducciones para los logros y trofeos. Como estos archivos hay que enviarlos a los servidores de estas dos compañías, han de seguir un tipo de formato determinado. Si todos los archivos de localización tuvieran formatos compatibles, crear una herramienta destinada a los traductores merecería la pena porque se podría reutilizar.

    Como algunos habéis mencionado, la seguridad es un gran problema. Pocas compañías cuentan con traductores internos para todos los idiomas en que localizan. La mayor parte del trabajo de traducción se hace de forma externa, y con lo importante que es la confidencialidad en el mundo del video juego, pocos desarrolladores se atreverían a desarrollar una herramienta de localización basada en Web.

    Otro punto a favor de Excel consiste en la corta vida de un proyecto de localización de un video juego. Para localizar un sitio Web que se va a actualizar a menudo, el uso de una aplicación tipo Trados es obligado, ya que puede crear proyectos a partir de muchos tipos de archivo Web y resalta claramente lo que ha cambiado. Un sitio Web puede tener una vida muy larga, pero un video juego AAA se localiza en 6 meses. Cuando el juego se encuentra en la tienda, se acabó; ya no hay que localizar nada más para ese juego (sin tener en cuenta los posibles ports, DLC, patches, etc.).

  20. @Adolfo
    con lo importante que es la confidencialidad en el mundo del video juego, pocos desarrolladores se atreverían a desarrollar una herramienta de localización basada en Web.

    ¿Quieres seguridad? Toma VPN. Por otra parte, sé de buena tinta que parte de Sony tiene un sistema de gestión de traducciones vía web. Eso sí, reconozco que Japón puede ser más reticente.

    puede crear proyectos a partir de muchos tipos de archivo Web y resalta claramente lo que ha cambiado.

    Ciertos elementos (de la misma saga, de la misma desarrolladora o para la misma consola) son comunes a más de un juego. No hablo sólo de las advertencias de seguridad, también está la interfaz o las menciones al hardware (memoria, mandos). Si estos recursos se llaman desde archivos externos, tanto la automatización como las memorias empiezan a tener mucho sentido.

    Para todos:
    Los desarrolladores no van a mover un dedo porque los traductores tengan que pelearse con Excels gigantescos, lentos, incompatibles y llenos de macros. Pero cuando les dices lo que pueden ahorrar en tiempo y dinero y los errores humanos que pueden evitar automatizando la gestión con flujos de trabajo, a los jefes de esos desarrolladores les hacen los ojos chiribitas.

  21. Efectivamente, a los “jefes” lo que les interesa es la pasta y el tiempo, y solo por comodidad del traductor no creo que hagan muchos esfuerzos. Pero precisamente yo creo que se ahorraría tiempo creando algo más o menos estándar, y a la larga se evitarían quebraderos de cabeza, así que también comparto la idea de que exportar e importar todo usando un formato como XML o XLIFF nos ayudaría a todos.

    El problema es que claro, como decís, una empresa puede hacer todos sus archivos compatibles con tal formato, pero a saber lo que hacen otras. Quizás por eso mismo debería haber algún tipo de organismo que tenga como objetivo estandarizar las prácticas en localización de videojuegos (por suerte, en localización de software y páginas web sí que hay bastante hecho).

  22. Pablo Bouvier dice:

    Hola, Pablo:

    Félix es una excelente memoria de traducción de Ginstrom Software, lamentablemente poco conocida en el mundo de la traducción. Por si te interesa el tema sobre como hacer una memoria de traducción con Excel, aquí te dejo dos cositas que tal vez puedan ser de tú interés:

    a) un enlace a como crear “unidades de traducción” desde Excel:
    http://rectrad.wordpress.com/ (aunque, en realidad, es para pasar un glosario al formato uncleaned de Trados y, desde este, a una memoria de traducción,igual podría aplicarse a un bitexto en 2 columnas)

    b) un algoritmo de comparación de similitud de cadenas (distancia de levenststhein), junto con un ejemplo en Rapid-Q basic (de código abierto) que realice hace años para mis pupilos universitarios y que puedes descargarte aquí: http://www.box.net/shared/q0srokkqpy

    La distancia de levensthein lo que calcula es el número mínimo de variaciones (transposiciones, adiciones o borrados de letras) necesarios para convertir una cadena de texto en otra. Por aquí corren algunos otros algoritmos similares: http://www.dcs.shef.ac.uk/~sam/stringmetrics.html

    Un saludo
    Pablo

  23. Hola Pablo:

    Gracias por los enlaces. Le he echado un vistazo a tu código y me es un poco complejo de seguir, pero bueno, siendo un algoritmo como ese, es normal.

    ¡Muy interesante todo!

  24. Pablo Bouvier dice:

    Hola, Pablo:

    Rapid-q basic tiene algunas limitaciones, así que es posible que parezca más complejo de lo que en realidad es, ya que se tuvo que adaptar el algoritmo al lengaje. Probablemente, en Visual Baisc sería bastante más sencillo. En el algoritmo de la wikipedia también se entiende mejor.

    Lo que en realidad hace el algoritmo es recorrer una matriz formada por las dos cadenas que se com0paran, verificando si tiene que hacer una o más operaciones de inserción, borrado o trasposición para convertir la primera en la segunda.

    Aquí ( http://en.wikipedia.org/wiki/Levenshtein_distance ), si sigues los pasos del algoritmo sobre las matrices que dan de ejemplo(kitten/sitting)o (saturday / sunday ) resulta más fácil de seguir.

    Por cierto, a mi también me costo lo suyo entenderlo las primeras veces que lo leí, hasta que hice todas las operaciones en papel. Pero, no tuve más narices que asimilarlo, porque estaba obligado a explicarlo luego… ;-$

  25. Vaya, no había probado a buscar en la Wikipedia, la verdad es que es mucho más claro todo.

    Lo tendré en cuenta si alguna vez me animo a hacer un programa de memoria de traducción… ¡Gracias de nuevo! 🙂

  26. Me ha gustado mucho tu post, ya tienes una fans mas, felicidades

  27. ¡Muchas gracias, Carla! 😀

Speak Your Mind

Responsable » Pablo Muñoz Sánchez (servidor).
Finalidad » gestionar los comentarios.
Legitimación » tu consentimiento.
Destinatarios » los datos que me facilitas estarán ubicados en los servidores de Dinahosting (proveedor de hosting de Algo más que traducir) dentro de la UE. Ver política de privacidad de Dinahosting. (https://dinahosting.com/legal/proteccion-datos).
Derechos » podrás ejercer tus derechos, entre otros, a acceder, rectificar, limitar y suprimir tus datos.

*