domingo, 8 de febrero de 2009

LOCALIZATION: DOCUMENTATION

Most localization projects consist of different stages that need different technical and linguistic approaches. When localizing IT applications, for example, the translator usually receives two different kinds of texts: software (i.e., onscreen text displayed on the application interface) and documentation (i.e., user’s guides, EULAs, etc). Each of these parts of the product requires specific tools and follows specific procedures. Let’s continue with the second stage: documentation.
.
La mayoría de los proyectos de localización constan de distintas fases que precisan distintos enfoques técnicos y lingüísticos. En la localización de aplicaciones informáticas, el traductor suele recibir dos tipos de textos: el software (es decir, el texto que aparecerá en la interfaz de la aplicación) y la documentación (es decir, el manual del usuario, acuerdos de licencia, etc.). Cada una de estas partes del producto requiere herramientas concretas y siguen procedimientos específicos. Sigamos con la segunda fase: la documentación.
.
Tal y como explicamos en el artículo anterior, en el sector de la traducción de productos informáticos, el flujo de trabajo dista mucho de ser lineal. La mayoría de los proyectos constan de una serie de procesos dependientes entre sí que afectan directamente a la labor del traductor: desarrollo del producto, redacción de los textos originales, extracción del material traducible, pretraducción, traducción, inserto del texto traducido, revisiones técnicas, revisiones lingüísticas, cambios del cliente, modificaciones del producto, actualizaciones de los textos originales y vuelta a traducir. Como se ve, el traductor suele depender al 100% del cliente en cuanto a qué traducir, cuándo traducirlo y cómo traducirlo. Muchos de estos factores vienen determinados por el enfoque adoptado por el cliente para la localización de sus productos. Y ese enfoque, como en todo negocio, viene determinado por el factor económico. En resumen, cuanto mayor sea el interés económico en la localización de un producto informático, más exhaustivo será el proceso de traducción y mayor será la calidad del producto localizado.
.
El esquema más extendido suele consistir en traducir en primer lugar el software (menús, botones, mensajes en pantalla, etc.) y, una vez se cuenta con ese material de referencia básico, comenzar a traducir la documentación que suele acompañar a todo producto (manuales, guías, contratos, publicidad, etc.). Hoy en día, el grueso de esa documentación suele elaborarse en formato PDF, por lo que su conversión a otros formatos traducibles no suele presentar ningún problema: se convierte a xml y se puede traducir tanto con TagEditor como con SDLX. Existe sin embargo, una herramienta quizá más interesante para traducir este tipo de guías: Idiom.
.
Idiom, además, del CMS Worldserver del que ya hablamos, cuenta con una herramienta CAT que nos ofrece una gran cantidad de opciones para traducir. Si trabajamos con Worldserver, Idiom nos permite elegir los xml que queramos incluir en nuestro archivo para traducir, un archivo comprimido con extensión .xlz en el que, además, se incluye tanto la memoria de traducción como la base de datos terminológica asociadas a esos xml. Una vez que tenemos ese archivo xlz, lo abrimos como si fuera un zip o un rar y especificamos las carpetas donde se guardarán: los xml que queremos traducir, convertidos en formato de Idiom para editar (extensión .wsprj); la memoria de traducción asociada (extensión .wstm); y la base de datos terminológica asociada (extensión .wstd). Durante el proceso de guardado, la memoria de traducción pretraduce automáticamente los xml. Es decir, cualquier segmento de los xml que coincida al 100% con un segmento de la memoria, se traducirá automáticamente. Además, Idiom cuenta los llamados ICE matches (in-context exact matches). Este tipo de segmentos no sólo registran una coincidencia textual del 100% sino que además en la memoria de traducción aparecen en el mismo contexto que en los archivos que vamos a traducir, lo cual garantiza una mayor seguridad en cuanto a la adecuabilidad de la pretraducción.
.
Una vez abrimos el archivo wsprj, veremos esta interfaz:
.
Como se puede apreciar, gráficamente, se asemeja a SDLX: dos columnas de texto, ventanas inferiores para fuzzies y búsquedas, colores asignados a cada tipo de segmento, etc. Sin embargo, cuenta con una serie de opciones adicionales que lo hacen aún más útil:
.
-Pretraducción automática.
.
-ICE matches.
.
-Búsqueda automática en la memoria al pasar de segmento en segmento, ya se trate de segmentos traducidos manualmente, fuzzies, 100% o pretraducidos (imprescindible para la fase de revisión).
.
-Búsquedas de palabras, propagación de traducciones y actualización de la memoria en uno o en todos los archivos.
.
-Varias categorías de segmentos que permiten filtrar el contenido que vemos y procesamos. Por memoria: ICE matches, Exact matches, Fuzzy matches, Manual translation (los que hemos traducido nosotros), Autotranslated (propagados). Y por estado: Empty (sin traducción), No status (traducido pero sin estado), Pending Review (traducido pero no revisado) y Reviewed (traducido y revisado).
.
-Posibilidad de aplicar una memoria en uno o en todos los archivos, hacerlo a partir de un segmento determinado u omitiendo aquellos segmentos que hayamos marcado como revisados.
.
Cuando tenemos que traducir un gran volumen de palabras de documentación, además de contar con la opción de compartir archivos y memorias entre varios traductores* (ideal para un grupo de trabajo in-house), Idiom también nos da la posibilidad de crear varios archivos xlz para repartir el trabajo de manera individual, puesto que incluyen los archivos para traducir que nosotros elijamos y el material de referencia asociado en un solo paquete. Igualmente, si se vuelca todo el material traducible en un solo xlz, Idiom nos da la posibilidad de aplicar memorias externas de manera selectiva, de manera que varios traductores puede trabajar con distintas copias de un mismo xlz y después, aplicar cada memoria sólo en los archivos que cada traductor ha traducido. Un método sin duda más sofisticado que la función de partición de archivos de SDLX (función de la que también dispone Idiom, por cierto).
.
En resumen, una herramienta con muchas posibilidades tanto para traducir como para gestionar proyectos de gran tamaño de manera cómoda y sencilla. Más que recomendable.
.
*Esta opción requiere una configuración previa.
.

Etiquetas:

sábado, 17 de enero de 2009

LOCALIZATION: SOFTWARE

Most localization projects consist of different stages that need different technical and linguistic approaches. When localizing IT applications, for example, the translator usually receives two different kinds of texts: software (i.e., onscreen text displayed on the application interface) and documentation (i.e., user’s guides, EULAs, etc). Each of these parts of the product requires specific tools and follows specific procedures. Let’s start with the first stage: software.
.
La mayoría de los proyectos de localización constan de distintas fases que precisan distintos enfoques técnicos y lingüísticos. En la localización de aplicaciones informáticas, el traductor suele recibir dos tipos de textos: el software (es decir, el texto que aparecerá en la interfaz de la aplicación) y la documentación (es decir, el manual del usuario, acuerdos de licencia, etc.). Cada una de estas partes del producto requiere herramientas concretas y siguen procedimientos específicos. Comencemos con la primera fase: el software.
.
La traducción de software, como muchas otras, presenta una serie de particularidades que obligan al traductor a tomar ciertas decisiones tanto lingüísticas como metodológicas. Estas particularidades, en la mayoría de los casos, se refieren a los procesos por los que ha pasado el texto que el traductor tiene entre manos y los otros tantos por los que pasará su traducción. De manera esquemática, se podrían resumir en este gráfico:
.

.
Como se puede ver, antes de tener el texto listo para traducir, es necesario convertir los archivos de la aplicación (.exe, .dll, .sys, .rc, .html, .xlm, etc.) a formatos compatibles con la mayoría de los gestores de memorias de traducción para poder así extraer el texto traducible, aprovechar textos anteriores aplicando memorias de traducción y guardar la traducción del proyecto actual, de manera que se pueda aplicar a futuros proyectos. La principal desventaja de estas traducciones, si no se cuenta con los archivos originales o la aplicación en sí (en muchos casos, una versión o build de prueba), es la falta de contexto. No hay que olvidar que estos textos o cadenas de texto (strings) suelen tener asociadas funciones, formatos y emplazamientos concretos, circunstancias todas ellas que van a afectar, cuando no determinar, nuestras decisiones como traductores. Lo ideal sería que el traductor contara siempre con los documentos, aplicaciones originales, o al menos pantallazos (screenshots) para ver cómo se encuadrará su texto, con qué formato se verá y qué función tendrá. Como digo, eso sería lo ideal, porque no siempre es así.
.
Por eso, a la hora de traducir proyectos de software, conviene tener a mano herramientas desarrolladas específicamente para estos menesteres. Trados y SDLX, a pesar de que admiten muchos de estos formatos y cuentan con funciones muy útiles para el traductor, siguen sin contar con editores 100% WYSIWYG (es decir, que el traductor no siempre puede ver su traducción en el contexto en el que se integrará dentro de la aplicación). Para estos casos, como digo, existen herramientas especializadas en software, como Passolo*.
.
La gran baza de Passolo es la capacidad para “volcar” en un solo archivo editable una gran cantidad y variedad de elementos de software (resources), de manera que el traductor pueda acceder al texto susceptible de traducción, de elemento en elemento, de manera sencilla y ordenada. La interfaz, totalmente personalizable, puede dividirse en varias ventanas:
.


.
Una ventana en la que se muestra un árbol con todos los elementos de software (a la izquierda);
.
Otra ventana con las cadenas de texto para traducir, diferenciadas por colores (a la derecha, abajo): en azul, el texto traducido; en rojo, el texto por traducir; en negro, el texto aprovechado de proyectos anteriores; y en verde, las traducciones propagadas automáticamente a partir de lo que vamos traduciendo en el archivo actual.
.
Y otra con el texto tal cual se verá en la versión final, según se va traduciendo (a la derecha, arriba).
.
Además, el traductor puede abrir otra ventana (abajo) desde la que puede hacer búsquedas de palabras en la memoria (Concordance) o de segmentos similares (Fuzzy Matches) y copiarlos directamente en su traducción. Ésta es la forma más cómoda de trabajar, ya que desde aquí se puede marcar la traducción como “Por revisar” o “Revisada”, añadir comentarios a cada segmento y comprobar la ortografía.
.


.
La principal pega para el traductor es la relativa complejidad de las opciones de aprovechamiento de proyectos anteriores (leverage). Las memorias de Passolo se guardan en un formato .glo que también puede exportarse como .txt, pero para su reutilización se suelen precisar complementos (add-ins) específicos, por no hablar de la conversión de otros formatos de memoria (Trados, SDLX, Idiom) a Passolo, un proceso que muchas veces se complica por la multiplicidad de formatos de los elementos de software. Como decimos, se trata de un programa muy recomendable, pero sobre todo para expertos en localización con ciertos conocimientos técnicos en estas lides y que suelan tener que traducir grandes volúmenes de texto para aplicaciones informáticas. Todos los detalles técnicos, aquí.

.

*Otro programa de una empresa independiente fagocitado el año pasado por SDL. Más información, aquí.

Etiquetas:

sábado, 3 de enero de 2009

LOCALIZATION: WORKFLOWS

In the last years, more and more localization processes have turned to the so-called Globalization Management Systems (GMS), which belong to a broader concept called Global Information Management (GIM) by SDL, one of the companies more enthusiastic about this model. This way of working is based on multiple accesses to data and content that will be treated by different people on different stages of the localization process. Nowadays, there are dozens of tools to streamline these “collaborative” creation processes and a similar number of multinational companies are already making use of them to manage their localization needs.
.
Desde hace algunos años, la tendencia en los procesos de localización pasa por los llamados Globalization Management Systems (GMS), que forman parte de un concepto más amplio que SDL, una de las empresas que más está apostando por este modelo, denomina Global Information Management (GIM). Esta forma de trabajo se puede resumir en un acceso múltiple a los datos y contenidos con los que trabajan diferentes individuos en distintas fases del proceso de localización. Hoy en día, las herramientas para facilitar estos procesos de creación “colaborativa” se cuentan por decenas, al igual que las compañías multinacionales que hacen uso de estas herramientas para gestionar sus necesidades de localización.
.
En cuanto a los traductores, ya llevamos mucho tiempo acostumbrados a trabajar con materiales casi exclusivamente electrónicos. Del papel se pasó al disquete, luego al CD‑ROM, para pasar al ftp y a los adjuntos del correo electrónico o, como en este caso, a las interfaces web. Nunca fue tan fácil y rápido acceder a los materiales necesarios para llevar a cabo el trabajo, de principio a fin: textos originales, memorias de traducción, glosarios e instrucciones, todo en un mismo sitio y todo personalizado para cada traductor. De esta manera, cada individuo sólo puede acceder a los archivos que se le han asignado. Las tareas correspondientes quedan marcadas como pendientes, en proceso, listas para revisión o terminadas con un solo clic, de tal manera que la siguiente persona en hacerse cargo de esos archivos recibe un aviso automático en cuanto la fase anterior del proceso está completada. Estas interfaces suelen permitir descargas masivas y compresión de archivos por proyectos, además de mostrar recuentos de palabras detallados, y fechas de recepción y entrega de cada fase. La automatización de estas funciones se hace imprescindible en las empresas de localización, donde cada día se puede generar una veintena de flujos de trabajo, entre los FIGS, los idiomas nórdicos y los asiáticos. Un modelo muy extendido es el de Idiom Worldserver*, que cuenta con un Content Management System (CMS) muy apañado para los traductores.
.
Esto del CMS no es más que la interfaz web a la que se accede con un nombre de usuario y una contraseña. Gracias a estos datos únicos para cada usuario, Worldserver muestra tan sólo los archivos asignados a cada traductor para que éste seleccione aquéllos que contengan contenido nuevo o modificado (la cantidad de palabras traducibles se puede ver en la propia interfaz personalizable) y los exporte (es decir, los descargue en su unidad local). Durante el proceso de descarga, Worldserver aplica automáticamente la memoria asignada por el cliente a todos los archivos para que el traductor sólo tenga que traducir los segmentos nuevos o modificar los fuzzies. Una vez descargado el fichero del proyecto, que contiene tanto los archivos para traducir como las memorias y los glosarios correspondientes, se abre y se especifica la ruta en la que queremos guardar cada elemento. Después de traducir, lo único que hay que hacer es importar el proyecto (es decir, subirlo a Worldserver) y, desde la interfaz, marcar los archivos como completados, para que el cliente sepa que están listos. La gran ventaja de este sistema con respecto a los métodos tradicionales es la automatización de los procesos. Por un lado, cuenta con un sistema de notificaciones automáticas mediante correo electrónico que avisa al traductor cuando hay material nuevo para traducir en los proyectos que tiene asignados, sin necesidad de que un gestor de proyectos le tenga que avisar. Y, por otro, la aplicación automática de la memoria de traducción (cuyo archivo original está ubicado en el propio Worldserver para mayor seguridad) a todos los archivos antes de empezar a traducir y la actualización, también automática, de esa misma memoria original una vez terminada la traducción.
.
En resumen, un modelo de trabajo que ahorra muchos pasos tanto a los clientes como a los gestores de proyectos, permite a las empresas de traducción acortar los plazos de entrega y también les facilita la vida a los propios traductores, que se pueden olvidar de ciertas tareas bastante pesadas, como aplicar y actualizar memorias, para centrarse en la traducción.
.
* La página se puede mostrar con errores porque SDL se comió Idiom a principios de año y todavía no han tenido la decencia de actualizar la información sobre los productos de la empresa. Más información, aquí.
.

Etiquetas:

jueves, 23 de octubre de 2008

LOCALIZATION: WHERE & WHEN

Most localization companies sell their services as linguistic experts highlighting the importance of adapting the clients’ products to the local market. By “adapting” they usually mean reshaping the product (i.e., the linguistic contents of the product) so that it could be appropriate or suitable to the target reader. But such appropriateness or suitability is not a single and fixed concept, it depends on the target country or region and on the target terminology development stage.
.
La localización es uno de los sectores de la traducción en los que suele estar más presente el criterio de coherencia terminológica. Hasta tal punto es así, que todo el flujo de trabajo depende de los contenidos de las bases de datos terminológicas (referencias válidas para todos los textos de un proyecto, cliente o temática) y de las memorias de traducción (material traducido anteriormente válido para proyectos o lotes futuros). Sin embargo, por su naturaleza, los idiomas no suelen ser ni universales ni atemporales, sino que varían dependiendo la región en la que se hablen y no dejan de evolucionar.
.
DÓNDE
.
Lo más habitual cuando se trabaja con más de una variedad dialectal de destino es traducir del idioma original a una de las variedades y, de ahí, adaptar la traducción a las demás (siempre que dichas variedades no presenten diferencias sustanciales o impliquen dificultades técnicas). En el caso de los proyectos de localización cuya lengua de destino es el español‑castellano*, la adaptación entre variedades se suele ceñir a una revisión de la terminología empleada en la traducción original y a alguna que otra reformulación sintáctica. En cuanto a qué términos son susceptibles de revisión, dependerá en gran medida del tipo de texto y de proyecto. A continuación se puede ver una tabla de correspondencias, a modo de ejemplo, con algunos términos adaptables entre el español de Latinoamérica** y el español de España que suelen poblar los proyectos de localización de software y páginas web.
.
CUÁNDO

Otro de los factores que pueden influir en la adaptación lingüística de los proyectos de localización es el momento en el que realiza la traducción. El caso de la informática, por su enorme difusión y rápido desarrollo, nos ha permitido comprobar claramente hasta qué punto pueden evolucionar las traducciones de un mismo concepto a medida que éste se va asimilando y extendiendo en la cultura de destino (por ejemplo, hoy en día en los medios electrónicos no es raro encontrar «email address» traducido simplemente como «dirección de correo», sin necesidad de especificar de qué tipo, puesto que el correo electrónico se ha impuesto al correo postal como principal medio de transmisión de información escrita entre particulares). Existen, por el contrario, otras traducciones cuya «estandarización» en un momento determinado ha obligado a arrastrar calcos, errores u omisiones («soporte técnico», «fichero»/«archivo», «en tiempo real», etc.). Actualmente este proceso de asimilación se puede ver en algunos términos que siguen sin encontrar una traducción fija en castellano, tanto en los países latinoamericanos como en España. Por tanto, no es rara la convivencia de distintas propuestas de traducción, asimilaciones fonéticas o, en la mayoría de los casos, omisiones de su traducción***.
.
Esta situación de inestabilidad terminológica puede venir dada por la complejidad del concepto, la falta de un equivalente lingüístico exacto en castellano, la propiedad del término (en caso de que éste corresponda a un sistema o dispositivo patentado), las limitaciones técnicas del proceso de localización o incluso la propia postura o preocupación por la lengua de los organismos que actúan como referentes terminológicos en estos casos, como los fabricantes o desarrolladores (Microsoft, Apple, Google, etc.). Veamos algunos ejemplos:
. Así pues, incluso en este tipo de textos aparentemente reglados y deshumanizados, es esencial ser consciente de los lectores/usuarios a los que va dirigido el texto/producto y de las coordenadas espacio‑temporales en las que están inmersos para ser capaz ofrecerles una traducción lo más acorde posible a sus expectativas.

* Para las variantes, véase Español de España, European Spanish, Castilian, Español neutro, International Spanish, mid-Atlantic Spanish, Español latinoamericano, LatAm, LA Spanish, U.S. Spanish, etc. Más detalles, aquí.
.
** A pesar de tratarse de ejemplos extendidos en varias regiones de Latinoamérica, muchos términos pueden presentar traducciones distintas en cada país. Más detalles, aquí.
.
*** Entre otros ejemplos, es muy frecuente el empleo de sustantivos en casa partir de sistemas o denominaciones comerciales: mp3, PDF, iPod, iPhone, Mac, etc.
.

Etiquetas: ,

miércoles, 24 de septiembre de 2008

VIDEOGAMES LOCALIZATION: THE DARK SIDE

To make their IT products available in other countries, many companies need to ‘recreate’ their products on a linguistic level. Such a linguistic operation is usually constrained by many technical requirements. In the case of videogames, those requirements are even more difficult to meet, since the translation has to take into account many other textual and extra‑textual circumstances that affect the final product on many different levels. Being aware of all the aspects, players, processes, constraints, tools and special needs of this industry might be the best way to 'learn to translate videogames'.
.
En los últimos años, uno de los sectores que más negocio ha generado para la traducción audiovisual es el de los videojuegos. El cuidado cada vez mayor con el que se desarrollan estos productos y la creciente interacción lingüística que exigen algunos de sus géneros está convirtiendo a ésta en una de las ramas más rentables de un sector de la traducción que no se destaca precisamente por lo generoso de sus tarifas. Además, la proliferación de empresas dedicadas exclusivamente a la localización de videojuegos (además de los propios desarrolladores, como Nintendo o EA) está ayudando a abrir puertas profesionales en un mundillo como el audiovisual que tradicionalmente no ha sido lo que se dice accesible.
.
Al contrario de lo que ocurre con las modalidades «clásicas» de TAV, existe relativamente poca literatura sobre la localización de videojuegos en castellano, aunque de un tiempo a esta parte se estén empezando a publicar más artículos al respecto a través de revistas, universidades y blogs personales. Si en algo coinciden todos estos artículos es en la multiplicidad y complejidad de actividades técnicas y lingüísticas que suele implicar este tipo de proyectos. Desde el punto de vista del traductor, es importante conocer algunos de los aspectos propios de esta industria que afectan directamente a su labor:
.
EL FLUJO DE TRABAJO
.
En la mayoría de los casos, se trata de proyectos de larga duración en los que intervienen muchos agentes que trabajan simultáneamente en varias fases dependientes entre sí. Esto quiere decir que el flujo de trabajo rara vez va en una única dirección: las revisiones, supresiones, adiciones y versiones actualizadas de textos originales y traducciones es algo con lo que el traductor ha de contar (sobre todo ahora que muchos juegos cuentan con actualizaciones descargables a través de Internet desde las propias consolas). En este tipo de macroproyectos de localización, el castellano se suele englobar en el llamado grupo FIGS (French, Italian, German and Spanish) que cubre la mayor parte de Europa Occidental, por lo que es frecuente que se traduzca a estos cuatro idiomas al mismo tiempo, partiendo generalmente del inglés estadounidense o británico, ya sea como idioma original o como traducción de un original japonés. Esta forma de trabajar, además de dar más margen a la hora de las entregas, ya que la fase de conversión de archivos y maquetación lleva necesariamente más tiempo, supone una gran ayuda al traductor, puesto que suele existir un mecanismo de consulta de dudas que comparten los cuatro idiomas (las llamadas «queries») en las que cada traductor puede hacer preguntas al cliente o desarrollador, además de ver respuestas a preguntas de otros idiomas. Un caso recurrente en el que este procedimiento se hace necesario es el de los guiones, en los que no siempre se incluye un mínimo de contexto para encontrar la equivalencia adecuada en cuanto a registro, tratamiento entre personajes o incluso saber si éstos son masculinos o femeninos.
..
LAS RESTRICCIONES TÉCNICAS
.
Precisamente la falta de contexto suele ser una de las causas habituales de errores de traducción en este tipo de proyectos. Y es que, si bien en algunos casos se tiene la posibilidad de acceder al videojuego en el idioma original (y el tiempo necesario para resolver dudas de contexto), esto no suele ser lo habitual, en especial si el traductor trabaja desde casa. Algunos de los rasgos más frecuentes de estas traducciones son consecuencia de esta circunstancia. Por ejemplo, la falta de cohesión textual al traducir líneas sueltas sin ilación de sentido; el uso de hiperónimos en lugar de utilizar vocablos específicos; en el caso del inglés como LO, la traducción de verbos por nombres o viceversa; la traducción de términos muy repetidos en inglés de una única manera en todos los contextos; o el uso de fraseología antinatural o poco idiomática creada a partir de terminología aislada (término genérico + término específico). Hay que decir, no obstante, que no son pocos los proyectos en los que los traductores cuentan con gran cantidad de referencias para evitar todos estos problemas, ya sea en forma de explicaciones específicas para la traducción, manuales del juego, capturas de pantalla, guías de personajes o vídeos.
.
Otra de las limitaciones que más afectan a las traducciones es la restricción de caracteres. Puesto que gran parte del texto que se traduce en estos proyectos aparece en pantalla combinado con imágenes, es necesario que éste se ajuste a unas medidas determinadas que no impidan el disfrute o desarrollo pensado para el juego. Este tipo de restricción puede venir dado por número de caracteres o por comparación con el texto de partida (casi siempre el inglés, que suele ser más económico en cuanto a espacio). De ahí que en muchas ocasiones se creen abreviaturas a partir del inglés («Lv. > Nv.»), se usen siglas de manera poco natural en castellano («WMD strike» > «ataque ADM») o acortamientos poco usuales en castellano («enemigos» > «enem».) o bien se omitan preposiciones en ciertos sintagmas («puntos fuerza», «empujón fuerza»). La importancia de acatar estas limitaciones de espacio, que en más de una ocasión dan lugar a traducciones francamente mejorables, bien la saben los encargados de probar las versiones localizadas de los juegos, los testers, que en más de una ocasión se ven obligados a sacar la tijera para que la cosa cuadre.
.
En el caso de los guiones para subtítulos, por ejemplo, este constraint espacial es bastante estricto, ya que, al tener que ajustar los textos a varios idiomas a la vez, se suele utilizar una única spotting list, normalmente creada a partir del inglés, por lo que todos los idiomas han de ajustarse al espacio y tiempo que requirió cada línea de texto en el idioma de Shakespeare y de Lucas. Además de esta limitación gráfica, en los guiones para doblaje también es necesario ajustarse lo más posible al original, si bien depende de cuál vaya a ser el uso de ese texto en el juego. Si no es necesaria ninguna sincronización (por ejemplo, si son voces de fondo, gritos de guerra o mensajes emitidos a través de algún aparato dentro del juego), la traducción no tiene por qué ajustarse al 100% a la longitud y forma del original, pero si hay que tener en cuenta la isocronía (duración de los enunciados), la sincronía cinética (movimientos de los «actores») y la sincronía labial, la cosa cambia. Al igual que en el doblaje «clásico» para cine o televisión, en el doblaje para videojuegos también existe la figura de director de doblaje, que es quien se encarga de estos retoques, pero es responsabilidad del traductor que su texto se ajuste en la medida de lo posible a la longitud del original.
.
LA TERMINOLOGÍA
.
Otro de los caballos de batalla de los traductores de videojuegos suele ser el uso de los términos impuestos por las compañías que han desarrollado las plataformas, es decir, Sony para PS2, PS3 y PSP; Nintendo para Wii y DS; y Microsoft para Xbox. Puesto que el 99% de los juegos que salen al mercado lo hacen en una o varias de estas plataformas (aparte de la versión para PC), es imprescindible tener a mano un glosario de cada una de las plataformas validado por estas compañías. En este tipo de glosarios se suelen especificar las traducciones oficiales de los componentes de las consolas, los mandos, los menús offline y online, además de los mensajes en pantalla más recurrentes, traducciones que han de respetarse escrupulosamente. Dada la cantidad de empresas de localización y traductores que trabajan con sus productos, no es de extrañar esta exigencia de las multinacionales por estandarizar la denominación de sus productos en cada país. También las franquicias de videojuegos (por ejemplo, todos los juegos de un mismo personaje) suelen tener su particular glosario o base de datos terminológica. Por eso, en estos casos, lo mejor es contar con alguna herramienta de control de calidad terminológica para garantizar al máximo la coherencia con todos estos glosarios. El lado oscuro de tanto control, a veces ejercido por agentes no nativos de la lengua a la que se traduce, son los posibles conflictos entre glosarios (a veces hay que decidir entre dos traducciones «oficiales» de un mismo término original) o la falta de naturalidad (en ocasiones, el traductor se ve obligado a utilizar dentro de un texto las formas invariables que figuran en los glosarios). En cuanto al resto de terminologías, tampoco está de más que el traductor tenga a mano algún que otro glosario de armas, deportes, mecánica o cargos militares, omnipresentes en muchos juegos.
.
Como hemos visto, la naturaleza híbrida de estos proyectos, a medio camino entre la localización de software y la traducción audiovisual, suele multiplicar los condicionantes que soporta la labor de traducción. Por eso, para ser traductor de videojuegos uno tiene que ser flexible, agudizar al máximo el ingenio, pero sobre todo, tiene que tener mucha, pero que mucha paciencia con sus clientes.
.

Etiquetas: ,

lunes, 22 de septiembre de 2008

MULTILINGUAL MEDIA

«A las pocas horas de producirse los atentados terroristas del 11 de septiembre, CNN decidió anular la emisión del resto de televisiones para que todas difundiesen lo que decía y mostraba la CNN de EE. UU. Es el caso de CNN en Español (para Latinoamérica) o CNN Internacional (para gran parte del globo). No sucedió lo mismo con CNN+ por tratarse de una joint venture y gozar de más independencia empresarial. Con esta medida, ¿qué mejor manera de controlar el mensaje de la CNN en todas sus delegaciones que traduciendo directamente lo que dice la cadena matriz? En el caso de CNN en Español los dos traductores oficiales de eventos y ruedas de prensa se dedicaron a traducir la señal que la CNN norteamericana ofrecía en directo. De esta manera, el mensaje que se traslada a través de todas las empresas del grupo queda controlado y es uniforme. El poder adquiere su máxima expresión y gracias a la traducción en directo puede llegar al resto de países que reciben estos canales. Una decisión en la que priman intereses sociales y políticos
.
Extraído del artículo:
.
El redactor-traductor en los grandes medios de comunicación con mercados multilingües: caso CNN, de Jorge Gallardo Camacho.
.

Etiquetas:

sábado, 20 de septiembre de 2008

AROUND TRANSLATION

.
More often than not, translation is just a part of a global process to produce texts following certain specifications and requirements. To meet these requirements, both freelance translators and translation agencies are asked to assume some tasks not strictly focused on translating words and meanings, but on assuring those words and meanings are transferred the right way. Spelling, grammar, punctuation, format or terminology are some of the issues freelancers and agencies must be aware of to produce quality translations. Solving these issues fast and efficiently is just a question of following some basic and standard procedures.
.
A pesar de lo que pueda parecer, el trabajo del traductor no termina cuando acaba de traducir. Normalmente, después de la traducción se suele seguir una serie de procedimientos para garantizar la calidad de ésta. Formalmente, estos procedimientos pueden llevarse a cabo por el propio traductor o por otro profesional, aunque esto nunca exime al traductor de velar por la calidad de su trabajo en la medida en que el tiempo y los medios lo permitan.

En primer lugar, y por básico que parezca, convendría recordar la necesidad de utilizar siempre un corrector ortográfico y gramatical, sin importar en qué plataforma estemos traduciendo. Algunas herramientas de traducción como SDLX cuentan con su propio corrector, aunque el más utilizado, por lo extendido de su formato, es el de Microsoft Word. Es importante conocer a fondo las particularidades del corrector (qué detecta como error y qué no) y las del proyecto (qué errores son los más comunes o esperables) para saber qué buscar a la hora de revisar el texto. En un proyecto largo de localización en el que se repiten las palabras «cargar», «cargando» y «cargado», por ejemplo, no sería descabellado hacer alguna búsqueda por si se ha quedado alguna «r» por el camino. También hay que tener presentes las preferencias del cliente (en caso, por ejemplo, de dos grafías válidas de una misma palabra, como ocurre con los pronombres demostrativos y el adverbio «sólo/solo») a la hora de revisar un proyecto, ya sea a mano o con herramientas automáticas. Muchas agencias de traducción cuentan con su propia guía de estilo para este tipo de casos, aunque se suelen adaptar a las exigencias del cliente final.

En segundo lugar, y también como tarea imprescindible para el traductor, se debe comprobar el formato del documento traducido para que se corresponda al máximo posible con el del original. Puede parecer una verdad de perogrullo, pero en un sector cada vez más acostumbrado a los gestores de memorias de traducción, son pocos los documentos que no se «pretraducen» con un programa informático que puede descabalar formatos y estilos, ya estén visibles u ocultos. Si bien es cierto que en muchos casos el documento al que se enfrenta el traductor no es la versión final del texto ni tiene por tanto el formato definitivo, no es recomendable descuidar este aspecto, ya que, normalmente, cuando se recibe un texto traducido, se da por hecho que el formato es idéntico al del original, y se maqueta de acuerdo a esa suposición. Un par de operaciones básicas que no llevan mucho tiempo y evitan problemas a posteriori:

1) Hacer una «lectura vertical» de la traducción cotejándola con el original, mirando si hay mayúsculas o minúsculas fuera de sitio, si faltan puntos o comas (o si están repetidos), si las partes del texto se ajustan al espacio previsto en el original, etc.

2) Hacer una búsqueda de dobles espacios y sustituirlos por un espacio, y de espacio + marca de párrafo ( ^p) y sustituirlos por marca de párrafo (^p). Tampoco está de más buscar todos los nombres propios compuestos (Los Ángeles, El País, etc.) y comprobar que entre las dos palabras que conforman el nombre se ha utilizado un espacio de no separación (^s), algo especialmente importante si se trata del nombre del producto o de la empresa del cliente. En Word, estos caracteres se encuentran en el menú «Buscar y reemplazar» > «Más» > «Caracteres especiales».

Esto en cuanto a las tareas propias de los traductores. Si hiciéramos las veces de revisores de un texto ajeno, lo primero que tendríamos que saber es qué nos piden exactamente. En el mundo de la traducción globalizada, se suele hacer una distinción entre las tareas que comprende la revisión de traducciones:
.
Revisión lingüística (review o linguistic review): corrección ortográfica, ortotipográfica, gramatical, semántica, estilística, etc. Una de las herramientas más empleadas en estos casos es el Control de cambios de Word, que permite tachar y escribir texto sin eliminar la traducción original (siempre que no se esté utilizando Trados Workbench), además de incluir notas al margen para las correcciones de estilo, normalmente marcadas como sugerencias. Si se utiliza TagEditor, este programa sí incluye una herramienta para añadir comentarios. Si la traducción se ha realizado con SDLX, los archivos de este programa (.itd) incluyen la opción de anotar comentarios en cada segmento sin alterar la traducción. Esta opción resulta más cómoda para el traductor, ya que el revisor puede generar un archivo aparte en formato xls o html (Utilities > Export to Excel / Export to HTML) en el que los comentarios se ven con un simple golpe de vista. Otra herramienta similar que también sirve para documentos de Word y de TagEditor es ApSIC Comparator (gratuito), aunque ésta no admite comentarios, sólo compara las diferencias entre el documento revisado y el traducido. Más detalles, aquí.
.
Revisión terminológica (proofreading): comprobación de la terminología empleada en el texto traducido cotejándola con memorias de traducción, glosarios y bases de datos terminológicas. Para esta parte de la revisión existen aplicaciones específicas como QA Check del paquete SDLX, que genera un informe a partir de un archivo .itd con todo tipo de información relevante para el revisor. Además de las posibles incoherencias del texto con respecto a los términos de una base de datos terminológica en formato .tdb, detecta dobles espacios, signos ortotipográficos fuera de lugar, frases no traducidas o errores de formato, todo totalmente personalizable por el revisor. Otro programa muy útil para este tipo de revisiones terminológicas es Xbench, también de ApSIC y también gratuito. Funciona con documentos de Word y de TagEditor y genera un informe similar al del QA Check de SDLX, con la particularidad de que es posible cargar varios glosarios, bases de datos y memorias a la vez para comprobar la coherencia terminológica. Más detalles, aquí.
.
Control de calidad (QA check): se trata de un procedimiento habitual que llevan a cabo las propias empresas o agencias de traducción, ya sea de manera interna o externa, para verificar la coherencia terminológica, la funcionalidad técnica o el formato final de sus proyectos, sobre todo cuando se trata de proyectos de gran envergadura o en formatos más complejos. Hay varios tipos de controles de calidad. El terminológico ya lo hemos visto en el apartado anterior. En cuanto a la funcionalidad de los archivos, si bien no suele ser competencia directa del traductor o revisor, no está de más tener algunas nociones en cuanto a la conversión de archivos o las etiquetas y colores que emplean herramientas como TagEditor o SDL Edit para codificar comandos y formatos, y así evitar meteduras de pata fáciles de prevenir pero engorrosas de solucionar. Lo que sí es (o debería ser) tarea del revisor es la comprobación lingüística del formato final de la traducción (el llamado DTP Check), ya que en ese penúltimo paso es donde se pueden corregir aspectos como la puntuación (la necesidad o no de puntos finales en algunas frases), los dobles espacios entre frases (algo que no siempre se puede ver si se traduce y revisa con gestores de memorias de traducción), la corrección y adecuación de los textos integrados en imágenes (que, en ocasiones, no se someten a los mismos procedimientos de revisión que el resto del texto), el formato de las cifras (que es posible se haya pasado por alto si éstas no forman parte del texto), la longitud de los textos y el tamaño de las secciones diseñadas para ellos, la separación silábica de las palabras entre renglones o los posibles despistes de maquetación. Este tipo de revisiones pueden hacerse tanto en los propios documentos maquetados (agregando comentarios con Word o Acrobat Reader, por ejemplo) como utilizando modelos específicos estandarizados (la mayoría de las agencias y empresas de traducción cuentan con sus propios modelos).
.
Todas estas comprobaciones, aunque no forman parte del proceso de traducción propiamente dicho, son imprescindibles para conseguir un mínimo de calidad en el producto final que es el texto traducido.
.

Etiquetas: ,