miércoles, 23 de febrero de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (Parte IV)

Como estuve explicando antes, para conseguir un buen producto localizado, hay dos cosas que son básicas:

a) Una buena localización

b) Un buen control de calidad

El proceso para obtener una buena localización ya lo expliqué en mi anterior entrada, así que, ahora pasaremos al siguiente punto:


B) CONTROL DE CALIDAD

Esta es la parte que todos los friquis adoran, y también la razón por la que mis amigos friquis españoles solían odiarme cuando trabajaba como tester J

Existe la creencia (falsa) de que el control de calidad es pasarse horas jugando un videojuego hasta que lo acabes… Veinte veces. No, no deberíamos considerarlo a la ligera. Un probador de juegos, o técnico de control de calidad, más conocido como tester, necesita mucho más que saber jugar a un juego para considerarse un buen tester.


¿Qué necesita un técnico de control de calidad (o tester)?

1. Capacidad para llevar a cabo tareas repetitivas

El proceso de testeo es una tarea repetitiva que puede durar desde un solo día a varias semanas, o incluso meses. Funciona de forma diferente dependiendo de si eres un técnico de control de calidad de funcionalidad, que trabaja con el juego en la lengua original, o uno de localización, que trabaja con el juego localizado, aunque las cualidades básicas necesarias sean las mismas.

El proceso empieza cuando el tester recibe una versión del juego, llena de errores. Si eres un tester de funcionalidad, tu jefe de proyectos te pedirá que te concentres en un solo nivel, por ejemplo, el nivel 1. Sin embargo, el nivel 1 se queda bloqueado justo al principio, cuando intentas matar al enemigo número 2 con una metralleta. No te das cuenta de la relación hasta que la consola se ha bloqueado, al menos, 10 veces. Por ello, decides escribir un bug en la base de datos de errores y usar el cuchillo para matarlo y, así, poder continuar con el nivel.

Ah, ¿que no sabéis lo que es un bug?

Un bug es «un error o defecto en un programa que puede hace que no funcione correctamente o cuyo resultado sea incorrecto o inesperado». Así que, el tester introduce todos estos errores en una base de datos que comparte con todos aquellos involucrados en la creación del juego, de forma que los programadores pueden ver la lista cosas fallan en el código del juego arreglarlas (cuando puedan o quieran). Simplificando, esta base de datos es la forma en que los probadores y los desarrolladores se comunican, aunque, a veces, la «comunicación» pueda ser difícil.


Pero volvamos al testeo... Hemos quedado que te pasas 8 horas al día jugando al mismo nivel, cambiando la metralleta por el cuchillo cuando ves el enemigo número 2 (vas por detrás, sin que te vea, para degollarlo), vuelves a equiparte con la metralleta y sigues jugando hasta que terminas el nivel. Y vuelta a empezar. Al principio parecerá muy emocionante y divertido; sin embargo, tras tres o cuatro meses empiezas a plantearte si no sería mejor trabajar en McDonalds J

2. Atención por los detalles

Esto podría parecer fácil: observación pura y dura. Pero no es así. Cuando has jugado al mismo juego (o el mismo nivel) 20 veces, la parte mecánica del cerebro empieza a acostumbrarse y, por ello, empiezas a jugar como una máquina, sin fijarte en apenas nada. Seguramente pueda explicaros la secuencia de movimientos y enemigos del primer nivel de Tomb Raider: Legend, el cual habré jugado como 30 veces por plataforma, es decir, 7 plataformas. Así que, creedme cuando os digo que no es ni fácil ni divertido (al cabo de varias repeticiones) J

Imagino que la parte más importante de esta atención por los detalles necesaria se basa en tener una buena memoria visual de forma que el tester pueda darse cuenta de todo aquello que no es como era antes o como debiera ser y, así , poderse asegurar de que todo está bien.

3. Conocimiento de idiomas

Incluso si eres tester de funcionalidad y solo hablas un idioma, es importante tener un buen conocimiento escrito del dicho idioma. Y, ¿por qué?, os preguntaréis. Pues por el simple hecho de que, puede que aquellos que escriben los textos originales no es que sean los más diestros en el mundo literario (son programadores e informáticos; no les das trabajo para que te escriban una novela sino para que te programen), de manera que el tester tendrá que asegurarse de que el texto original del juego es preciso y no confunde al jugador.

Si eres un tester de localización, el buen conocimiento escrito de tu idioma materno es aún más necesario, ya que serás el último paso dentro de la cadena de localización y deberás asegurarte de que el texto traducido sea correcto, exacto y, bueno, todo en el mismo idioma.

4. Experiencia con videojuegos

Que te guste jugar a videojuegos y que, además, se te dé bien, sirve de mucho en esta profesión, porque de verdad te vas a pasar horas y horas jugando. Sin embargo, si tuviese que escoger entre alguien que no tiene ni idea de escribir correctamente ni deletrear pero que juega a videojuegos, o alguien con un gran dominio de su idioma materno pero que, sin embargo, no sepa mucho de videojuegos, sinceramente, me pillo al filólogo. Todos podemos aprender a jugar a un videojuego en cierto tiempo. Enseñar un idioma es mucho más difícil.

5. Dotes de comunicación

No es tan fácil como parece. Comunicarse no es hablar, sino asegurarse de que se envía el mensaje correcto y que llega a la persona adecuada. Como en cualquier empresa, la comunicación entre los trabajadores es importante. De la misma forma, una buena comunicación entre los probadores y el resto de personas involucradas en el proceso de creación del juego es imprescindible. En algunos casos, puede que el ingeniero en localización haya encontrado un error importante que haga que el juego entero se fastidie y, por ello, es mejor detener el proceso de testeo y pedir a los desarrolladores que envíen una nueva versión que trabajar sobre una versión con la que apenas se puede hacer nada. Si el proceso se detiene, evitaremos tener que hacer lo mismo dos veces. O, por ejemplo, como me ha pasado varias veces, necesitas que el juego esté en tu idioma, pero la versión que te han dado está entera en otro idioma, así que, no tiene sentido seguir testeando. En estos casos es mejor, más rápido y más eficiente comentárselo a tu supervisor o al jefe del proyecto para que llame a los desarrolladores y les pida una versión nueva. Si no eres buen comunicador, podrías no darle importancia y tardar en comunicarlo, lo que retrasaría el proceso de testeo.

6. Saber qué quiere el cliente

Esto suelen ignorarlos tanto los distribuidores como los desarrolladores y, aún más, si los testers no forman parte de la compañía. En el caso de los videojuegos, ¿quién conoce a la perfección qué es lo que el jugador (o gamer) quiere? Aquel que pasa 8 horas jugando al juego, y ese es única y exclusivamente el tester. Muchas veces he trabajado con gente que me decía qué tenía que hacer pero que no habían cargado el juego ni una sola vez. ¿Cómo pueden entender el problema que hay o lo que debería cambiar si no conocen el juego por dentro? Eso sí, si el juego es una mierda, por supuesto, culpan al tester… Esto… ¿perdona?

7. Buen conocimiento de los estándares de los titulares del formato

Este punto es más específico para los videojuegos de consola y de PC, pero también pueden verse de otro modo en otros juegos como los juegos de apuestas, los de iPhone o, incluso, los juegos el línea en portales tipo Facebook. En el caso de los últimos, hay un poco de flexibilidad, pero aún necesitas conocer lo básico sobre sitios web. En el caso de las consolas y los juegos para PC, es decir, Sony, Nintendo y Microsoft, los estándares son, para ellos, lo más importante del juego. Si el juego se puede jugar y los estándares usados son correctos, las compañías aprobarán la publicación de los juegos. Sin embargo, si tienes el juego más impresionante pero los estándares no están a la altura de lo que te piden, no aprobarán el juego y el desarrollador o distribuidor dueño del juego podrá pasarse mucho tiempo y gastarse mucho dinero para conseguir solucionar el problema.

Lo gracioso es que, mientras trabajaba no solo como tester sino también como jefe de proyectos, me vi obligada, en más de una ocasión, a dar lecciones sobre estándares a algunos desarrolladores. Creedme, no es divertido, en especial porque casi nunca te creen.

Así que, a todos los traductores, testers, productores, programadores y desarrolladores del mundo: por favor, haced los deberes y aprender los estándares, que no cuesta nada y saldréis ganando.


En resumidas cuentas, para conseguir llevar a cabo un buen control de calidad, no basta con entretenerse con el juego durante horas sino que también hay que prestar atención, conocer muy bien tu propio idioma, saber qué quiere el cliente, conocer las exigencias de los creadores del formato y, además, saber comunicarse con aquellos que están metidos en el meollo contigo.

domingo, 13 de febrero de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (Parte III)

En mi anterior entrada, hablé sobre lo complicado y creativo que es, a veces, crear una buena localización que se adapte a las exigencias de la censura de un mercado en concreto, y lo bien que funciona dicho producto cuando está bien localizado. Pero os preguntaréis, ¿qué puedo hacer para que mi producto esté bien localizado?

3.- ¿Cómo conseguir un producto bien localizado?

Tras haber leído el punto anterior, seguramente os preguntaréis: ¿Qué tengo que hacer para conseguir una de estas localizaciones de calidad? Bueno, hay dos cosas que son básicas:

a) Una buena localización

b) Un buen control de calidad

Quizá pueda parecer algo simple y obvio, pero no siempre se realizan ambas, ni tampoco se realizan correctamente. Por ello, explicaré lo que, bajo mi experiencia, debería ser el proceso para conseguir un buen producto localizado.


A) BUENA LOCALIZACIÓN

1. Saber qué estás localizando.

Seguramente ya sabréis (por experiencia propia o porque os lo habrán contado) que una traducción sin contexto es mucho más difícil de hacer de lo que la gente suele pensar. Si te diesen una palabra sin ningún contexto, seguramente podrás encontrar 3-4 significados, o más, para dicha palabra. Lo mismo ocurre con los videojuegos. Aunque normalmente puedes encontrar contexto dentro del propio texto, también necesitas imágenes, o conocer qué hacen cada uno de los comandos, para entender de qué va la cosa. Por ello, el traductor debería familiarizarse con el juego, saber de qué va, quiénes son los personajes, etc. El cliente podría enviarte toda la información, capturas de pantalla, explicaciones… Todo esto es muy útil, pero, aún así, no se tiene la sensación de conocer el juego «al dedillo». Es por eso que creo que la mejor forma de conseguir este contexto es, simplemente, jugando al juego.

Familiarización con el producto → Jugar al juego/Usar el programa.


2. Asegurarse de que se tiene al traductor adecuado.

De la misma forma que usarás un traductor jurado para traducir un acta judicial o un contrato, o a un traductor científico para traducir un libro sobre Ciencia, ahora es el momento de conseguir el traductor especializado no solo en videojuegos pero también en el tipo de videojuego en concreto que vas a crear. Unos traductores se sentirán más cómodos traduciendo juegos de guerra, mientras que otros prefieren juegos más creativos. O a lo mejor necesitas un fanático de las armas o un experto en criminología para tu videojuego, o un friqui de Star Wars o una amante de la gimnasia. Podríamos compararlo con los gamers: algunos prefieren los juegos de tiros, otros se lo pasan mejor con juegos party o con puzles, mientras que otros prefieren juegos de deportes. Como localizador, podría aplicarse esta misma clasificación. Por poner un ejemplo un poco tópico: si le das un juego de Barbie sobre moda a un tío, seguramente sudará la gota gorda para conseguir una buena localización, mientras que si le das un juego de guerra a una tía, tal vez acabe agobiando a su novio con preguntas sobre términos bélicos. Por supuesto, también puedes investigar mucho y aprender a medida que haces este tipo de juegos, pero lo ideal es darle cada proyecto a la persona que podría hacerlo mejor y en el menor tiempo posible, ya que tiene la experiencia y el conocimiento adecuados.

Asegurarse de que es el adecuadoAsignar a cada traductor el proyecto que mejor se adapte a su conocimiento y experiencia.


3. Asegurarse de que el traductor lo entiende todo

Por desgracia, es bastante corriente encontrar textos originales (en mi caso, en inglés) que no están bien escritos (con errores y faltas de ortografía) o que tienen referencias culturales o que alguien de otra cultura o país no puede entenderlas. Por ello, los desarrolladores deberían asegurarse de que el texto original pasa por un revisor antes de enviarlo a los traductores para que lo localicen. Eso nos ayudará mucho a los expertos en localización. Por otro lado, si eres un experto en localización, asegúrate de centrarte solo en aquello que realmente conoces. Sin embargo, si ya estás traduciendo algo en lo que te especializas, no dudes en «molestar» al cliente, desarrollador o agencia, preguntándoles todo sobre el juego o pidiendo aclaraciones sobre cualquier problema que tengas durante la traducción. Si, aún así, sigues teniendo dudas, pregunta amigos expertos en el tema (todos tenemos un amigo informático, médico, policía, etc.).

Sí, amigos, esto es precisamente lo que una buena localización necesita: colaboración entre ambas partes.

Asegurarse de que el traductor lo entiende todo → Colaboración cliente-traductor.


4. Corrección

Aunque esto no es un punto obligatorio si has escogido al traductor adecuado, se recomienda hacerlo, sobre todo si se ha eliminado el proceso de control de calidad de la localización del juego. 4 ojos ven mejor que dos, y siempre es bueno tener una segunda opinión. Sin embargo, la corrección también podría incluirse en el siguiente paso que voy a explicar: el control de calidad.

Corrección → 4 ojos ven mejor que dos

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~


Sí, ya sé que muchos de vosotros sabéis todo esto, pero creedme, no todo el mundo se da cuenta de que no basta con darle el texto a un traductor y olvidarse del tema, o que la corrección no es necesaria si se han entregado 35 000 palabras al traductor para traducir a toda leche y entregar en un tiempo récord.

Pero eso no es todo. No basta con hacer una buena traducción y añadirla al código y, hala, ya se puede poner a la venta. Incluso aunque se tenga al traductor más experimentado, es aconsejable que la traducción siempre pase por la segunda parte del proceso de un buen producto localizado: EL CONTROL DE CALIDAD

Pero de ello hablaré en mi próxima entrega J

lunes, 7 de febrero de 2011

Lista de Conferencias y actividades para traductores, intérpretes y lingüistas

Dada la experiencia fructífera del pasado diciembre en la conferencia en Barcelona a la que acudí, me he decidido a presenciar muchas más este año. Ya sabéis que estaré seguro en la Conferencia Media4All que se celebra en Londres a finales de junio, pero de aquí a junio, hay muchas cosas que ocurren en el mundo conferenciante traductoril.

Por ello, y para tener una imagen visual de cuándo ocurre qué, he decidido hacer un documento con todas las conferencias, cursos, talleres, charlas y demás que hay en todo el panorama nacional y en otros países. La idea surgió hablando con otras dos traductoras, Yeyu y Jennifer, para hacer algo y compartirlo, pero como han estado muy ocupadas, al final me he decidido a hacerlo yo :) De momento, solo dispongo de los seis primeros meses del año, pero espero ir recibiendo más información de otros eventos que ocurran en el futuro. Por supuesto, cualquiera puede añadir los que conozca que no estén en la lista, además de sugerir cualquier cosa que pueda mejorar el documento.


A ver si, así, conseguimos conocer más eventos a los que acudir y conocernos entre nosotros :)

¡Que tengáis un buen día!

miércoles, 2 de febrero de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (Parte II)

Ya estoy de vuelta. Siento este descanso demasiado largo, pero entre Navidad, los viajes y el trabajo, no he tenido tiempo de continuar con mi exposición. Pero ya estoy de vuelta, con más ganas que nunca, para continuar con la explicación de mi presentación en el Congreso sobre Traducción y Accesibilidad en Videojuegos y Mundos Virtuales que se celebró en Barcelona.

[In English]

Estaba dando algunos ejemplos sobre mala calidad de localizaciones por una falta del entendimiento de la cultura tanto de partida como de llegada. Sin embargo una mala traducción no tiene por qué estar relacionada con la cultura. La mayoría de las veces se debe a la falta de información que el traductor tiene sobre el juego o al conocimiento reducido de la lengua de partida que el traductor pueda tener. Uno de los ejemplos que me chocó más fue algo que, a pesar de haber visto varias veces, solo me di cuenta de la gravedad cuando los creadores de Happy Aquarium decidieron añadir su versión pobremente localizada al español. Se trata de un juego muy simple, en el que el jugador tiene que cuidar de una pecera, comprando peces y asegurándose que los peces están alimentados en todo momento. ¡Está tirao! Sin embargo, parece que los desarrolladores se rindieron demasiado rápido a la hora de localizar el juego, ya que han dejado la mitad traducido y, bueno, ahora prefiero jugarlo en inglés que en Spanglish.

Como podéis ver, he marcado el texto que está traducido. El resto, incluidas las partes que siempre están presentes durante el juego, como los iconos de Rescue/Ignore, o incluso el ‘s después del nombre del jugador que tiene el Acuario, están sin localizar. ¡Hasta las pestañas del juego, en la parte superior! ¡Falta por traducir My neighbours!

También hay partes en los que hay texto cortado, seguramente por la falta del proceso de control de calidad posterior o, simplemente, porque el traductor no sabía cómo era el juego. Aunque siempre se podría haber evitado mencionando al traductor el número de caracteres máximo que caben en la caja de texto o reduciendo el tamaño de la fuente, porque dudo que el inglés quepa. En este ejemplo, podéis ver que falta el final de la frase:
¡Tu amigo ha sido [avisado!]
Mi siguiente ejemplo es algo que he visto muchas veces al corregir traducciones de otros traductores y es la prueba clara de que, además de conocer el idioma de salida a la perfección, la localización de videojuegos también implica conocer cómo funciona un juego por dentro, en qué consiste y para qué sirven las opciones de los menús y botones:

El texto marcado solía aparecer como «Dile a ellos». Sin embargo, en el juego, cada pecera pertenece a un solo jugador, así que, al hacer clic en este icono, solo se lo cuentas a UNA persona. Es decir, en español, debería ser en singular: «Díselo» o «Cuéntaselo». Esto se debe a que, en inglés, también se utiliza el plural (they, them, their) cuando no se quiere expresar el género de la persona o cuando no se sabe de qué género es la persona en cuestión. En español esto puede ocurrir solo en casos muy puntuales, por ejemplo en la expresión «Me esperan en casa», cuando solo te refieres a una persona (novio/novia, compañero/a de piso, cónyuge…), pero usas la forma en plural. En el caso de este juego, tampoco tendríamos problema en español, ya que, con la expresión «Díselo», conseguiríamos esa neutralidad (se puede referirse a él, ella, ellos o ellas). Me he encontrado con el mismo problema en otros juegos y diría que este error se debe, principalmente, a la falta de conocimiento del traductor sobre la gramática de este them, sobre qué supone, en verdad. Además, también se debe al desconocimiento por parte del traductor de la mecánica del juego: si el traductor hubiese sabido cómo funciona el juego, se habría dado cuenta de que, al hacer clic en el icono, la acción se dirige a tan solo una persona. A lo mejor en este caso, se habría preguntado por qué pone them si solo va dirigido a una persona, así que, le habría preguntado al cliente el por qué y, seguramente, el cliente se lo habría explicado.
Pero no todo son malas noticias… (¡YUPI!)
Lo bueno es que, la mayoría de las veces, la localización de un juego ocurre durante la creación del videojuego. Esto facilita el proceso de adaptación del videojuego a cierta cultura, bien porque los chistes o ironías no se entiendan en la cultura (y, por ello, podemos cambiarlos durante el proceso de Localización), o bien porque la cultura de llegada no acepta ciertas cosas que tiene la cultura de partida (o no están permitidas). Por ejemplo, en Alemania está prohibido mostrar sangre o decapitación en un videojuegos, o incluso ciertas escenas excesivamente violentas. No sé si ocurre también en el cine, pero en los videojuegos es así. Por ello, las compañías que quieran localizar su producto para el mercado de videojuegos alemán, deberán añadir una opción dentro del juego en la que la sangre no se muestre o, si se muestra, que no parezca que es sangre. Y eso puede llevar, muchas veces, a un alarde de creatividad por parte del desarrollador. La mayoría de las veces, se elimina directamente, o se utiliza otro color para la sangre, por ejemplo, el azul, o se hace transparente (solo ves el contorno de lo que podría ser la sangre).

En una versión de la saga de Hitman que testeé (creo recordar que la última entrega, Blood Money, y tampoco puedo asegurar al 100% que acabase en la versión final), además de tener la opción de desactivar completamente la sangre, había otra opción que convertía la sangre en flores rosas. Sí, flores. Es decir, cuando el Agente 47 mataba a alguien en la versión alemana, el muerto «sangraba» flores. ¿A que queda mono? Un poco cursi para mi gusto, pero funciona para la censura alemana. En este caso, la localización no supone un coste extra (más que unas cuantas horas del programador en programar esto y un poco de testeo después), ya que esta versión se incluye en todos los idiomas y se vende en una única SKU (o formato).
Sin embargo, también hay casos en los que el desarrollador deberá realizar una versión diferente para dicha cultura, que se venderá de forma separada, o en una SKU diferente.
Por exponer un caso curioso, en la versión alemana de Age of Conan: Hyborian Adventures, la cual tuve que testear durante un tiempo. Me quedé anonada cuando me dijeron que el desarrollador había tenido que preparar una versión especial de las diferentes formas que el jugador podía matar a un enemigo. No sé si habéis escuchado hablar de este juego, pero se trata de un MMORPG traducido a 6 idiomas y en el que el personaje principal (el jugador) tiene que conseguir reputación y experiencia matando, robando, ayudando a gente, etc. Para que tengáis una idea de a qué me refiero, imaginaos Conan el Bárbaro (me vale la imagen de Arnold Schwarzenegger), cargándose a todo el que se cruza por su camino, cortando cabezas y brazos con la espada y dejando los cuerpos en el suelo, desangrándose. Pues bien, esto es imposible que la censura alemana lo acepte. Por esta razón, Funcom, el desarrollador, tuvo que crear una versión nueva del juego en el que las forma de matar enemigos era «menos agresivas» (si es que se puede decir eso), y en las que el personaje nunca cortaría la cabeza o ninguna extremidad del enemigo. Además, la sangre sería inexistente. Debido a esto, el juego se vendía en una SKU diferente, es decir, en un DVD distinto y dirigido únicamente al mercado alemán.
Y sí, es verdad que estas versiones especiales pueden complicar las cosas y encarecer la producción del juego, pero si el juego es bueno y a los jugadores les gusta la localización, las ventas que la compañía pueda alcanzar justificarían completamente el gasto extra inicial. La localización no tiene por qué ser excesivamente cara y tampoco debería añadir ningún problema adicional al proceso, ya de por sí, problemático, pero si la localización es buena y el juego tiene éxito en el país de acogida, esto se vería reflejado en mayores ventas del producto final. Por ello, creo que no es correcto pensar que, a la hora de crear un videojuego, lo más importante es abaratar costes y despreocuparse por la calidad del resultado final. La solución «fácil» no es siempre la más barata, ni tampoco la que pueda proporcionar la mejor calidad.
Aún así, con la industria tan necesitada de profesionales trabajadores, flexibles y con experiencia, ¿por qué las compañías a menudo no contratan a profesionales con la experiencia y destreza adecuadas para llevar a cabo el trabajo lo más rápido posible y de la forma más eficiente? ¿Por qué seguimos viendo localizaciones de tan mala calidad (como el ejemplo que puse antes) una y otra vez? ¿Es mejor contratar a profesionales externos o hacerlo todo de forma interna? Esto lo explicaré en próximas entregas. Permanezcan a la escucha :)