Traducciones con restricción de caracteres II: porcentaje de ampliación

Hola a todos:
Como no tengo mucho tiempo para ponerme a escribir últimamente, os dejo aquí una actualización de un recurso sobre el que ya hablé hace unos meses. En concreto, en marzo publiqué una entrada en el blog acerca de la traducción con restricción de caracteres y di un Excel.
Hace unos días, estaba hablando con un PM sobre un proyecto de traducción de unas cadenas de firmware. La cuestión es que decía que el cliente no quería usar las herramientas de traducción habituales (hubo que usar un entorno de traducción propio del cliente que habían desarrollado), que el tiempo de trabajo era exiguo y que había que traducir y hacer un QA con restricción de caracteres, pero no sobre un límite fijado de caracteres (cosa que me extrañó, si una pantallita tiene 150 caracteres, los tiene siempre), sino con una restricción del 20% sobre el texto de partida (eso no es tan raro en SW, pero sí en FW).

Obviamente, la herramienta de trabajo era deficiente, así que como eran bastantes cadenas para hacer los cálculos a mano, se me ocurrió retomar la hoja de Excel que propuse en la entrada mencionada al principio y adaptarla. ¿Cómo? Muy sencillo añadí dos columnas: una, llamada Additional % allowed, en la que se especifica el porcentaje que la cadena puede superar la longitud del original en formato decimal (20% = 0,2), y la otra, Additional Characters allowed, es el resultado (redondeado hacia arriba) en caracteres que podemos usar de más en nuestra traducción. Finalmente, modifiqué la fórmula del resultado (String Status) para que tenga en cuenta el 20% adicional del que disponía.

He pensado que a los que trabajéis con desarrolladores directamente y os encontréis con situaciones como la que he descrito anteriormente, os puede resultar útil como complemento a la hoja de Excel original. Por supuesto, seguro que podréis mejorarla y adaptarla a vuestras necesidades para sacarle mayor partido. Os dejo pues la nueva hoja AQUÍ.

Bueno, eso es todo. Un saludo a todos y perdón por mi inconstancia como blogero.
Saludos,

Álvaro

Recomendación musical: no podía ser de otra forma… Noel Gallager, Dream On

QA y expresiones regulares en herramientas CAT (SDL Trados Studio) o generales (Microsoft Word)

Cuando llevas un tiempo relativamente razonable en el mundo de la traducción, llegas a la conclusión de que hay mucha gente capaz de hacer relativamente bien la gran mayoría de los trabajos que conforman el volumen de trabajo habitual de un proveedor de servicios lingüísticos para el que yo trabajo. Por tanto, si hay tantos profesionales (tanto recursos de producción freelancers como la propia competencia) capaces de ofrecer un nivel de calidad, pongamos 8, ¿qué puedo hacer para diferenciarme y ofrecer la máxima calidad (entre 9 y 10)?

Más allá de los procedimientos más habituales de la fase de control de calidad (QA) que se lleva a cabo normalmente tras finalizar la fase de traducción y de revisión (entre los que encontramos las clásicas revisiones ortográficas y gramaticales, las comprobaciones con perfiles automatizados tipo ‘igual puntuación source-target’, ‘comprobación de ¿? en español’, etc.), me gustaría llamar la atención sobre las expresiones regulares. Como define Microsoft, las expresiones regulares (regexp en inglés) no son más que fórmulas para identificar patrones de texto. La ventaja que ofrecen las expresiones regulares sobre estos sistemas de QA basados en glosarios y listas de palabras prohibidas es que superan la limitación de las propias palabras y van un nivel más allá. Veamos a lo que me refiero con un ejemplo concreto. Pongamos que tengo un proyecto de 90.000 palabras que tengo que repartir entre cuatro traductores (e incluso después entre dos revisores). A pesar de que les entregue mucha documentación lingüística (TM, glosarios) y referencias de estilo, es probable que haya divergencias en el resultado final en cosas como la localización de modelos de productos con números, números de piezas, el uso de mayúsculas tras puntos, el uso de un tipo de comillas u otras, etc.

Si yo deseo alcanzar la máxima calidad y limitarme a enviar el trabajo al cliente tal cual, podría usar las expresiones regulares para añadirlas al QA de mi herramienta CAT (prácticamente todas permiten hacerlo) para garantizar máxima precisión, coherencia y consistencia del material. A continuación, un ejemplo para ver a qué me refiero:

ST       Warning: Make sure all options are enabled before proceeding.

TT       Advertencia: Antes de continuar, compruebe que todas las opciones están activadas.

En este ejemplo, tendríamos un pequeño error puesto que tras : debería ir minúscula. Si tengo 90.000 palabras, ¿voy a revisar todos los : de mis archivos manualmente? La respuesta es no, para eso usaremos la siguiente expresión regular (en este caso escrita en un perfil de SDL Trados Studio y mostrada en el QA interactivo):

: [A-Z] (Descripción de la regla: si en el target se encuentra el patrón ‘dos puntos, espacio, cualquier caracter en mayúscula’ se genera una advertencia).

RexExp dos puntos

Con esta sencilla fórmula podemos identificar todos los fallos de este tipo en cuestión de segundos para corregirlos de forma mucho más eficaz. De hecho, si hubiésemos sido previsores, podríamos haber facilitado a nuestros traductores un perfil con expresiones regulares de este tipo para minimizar el número de potenciales errores de la última fase de QA al reunificar las 90.000 palabras repartidas entre los cuatro traductores.

Creo que este ejemplo muestra claramente que las expresiones regulares tienen un elevadísimo potencial que nos permitirá elevar la precisión de nuestra fase de QA y, consecuentemente, el de nuestro trabajo (tened en cuenta que podemos crear expresiones que se ajusten a todo tipo de necesidades usando tanto patrones como texto literal para, por ejemplo, comprobar que una dirección web siempre se localiza tal y como se muestra más abajo.).

Hay mucha gente que pensará que esto de las expresiones regulares es muy complicado pero, para los que sean de esa opinión, sólo puedo deciros que en un mercado tan competitivo hay que esforzarse por marcar la diferencia aprendiendo y ofreciendo servicios adicionales y de valor añadido. Además, las expresiones regulares son una habilidad transferible, se trata de un lenguaje universal que se puede aplicar en muchos contextos diferentes, de forma que es un conocimiento que podrás aplicar en miles de situaciones. A modo de ejemplo, un botón basta (la primera expresión, pero para búsquedas en Word):

Bueno, espero que os haya resultado interesante el tema de las expresiones regulares. A mí sí que me lo parece y por experiencia sé que te hace destacar entre los demás (incluso SIN SER un superexperto, como en mi caso). En Internet hay miles de sitios donde aprender a redactar regexps, seguro que encontráis alguno que os resulte adecuado para empezar.

Como siempre, en caso de duda, disparad.

Recomendación musical: un grupo que me pasó una compañera, Editors y su tema Bullets.

Traducciones con restricción de caracteres

Como casi siempre, debo empezar pidiendo disculpas por mi inactividad. La verdad es que incluso hay veces en que me planteo dejar de escribir temporalmente porque entre el trabajo como traductor, el de tutor y las tareas que tengo como diseñador y webmaster, el blog está más abandonado de lo que debería. Sea como fuera, me he decidido a publicar un post rápido pero que puede resultar práctico.

La cuestión es que hace más o menos unas tres semanas, recibí bastantes encargos de software en los que había que trabajar con restricción de caracteres y no se podía superar la longitud del texto de origen. A pesar de que esta era la instrucción específica del cliente y que los archivos iban en SDLX (que en realidad no es lo más indicado para hacer SW, pero eso ya es otra cuestión), no se me proporcionó ninguna forma de comprobar si mis traducciones superaban la restricción impuesta de forma automática (señalar toda la cadena y ver el recuento de caracteres en SDLX no es nada automático).

Total, que al final, tras comentarlo con dos de mis compañeros, David Valdivia y Ángel Martínez (profesionales excepcionales, cada uno a su manera y en su especialidad), llegamos a la conclusión de que lo mejor era crear un sistema de comparación de longitud de caracteres que pudiese usarse con cualquier traducción. ¿La solución? En lugar de buscar algo muy enrevesado, optamos por usar una herramienta de la que casi todos disponemos y que más o menos todos manejamos, Excel.

El proceso fue el siguiente: crear una hoja de Excel en la que se pueda cortar-pegar tanto el texto de origen como la traducción (la mayoría de las herramientas de traducción asistida te permite generar una vista de original-traducción enfrentada por columnas, o bien, puedes copiar todo el texto directamente –como en mi caso particular, en SDLX), a continuación, crear dos columnas en las que Excel inserte el recuento de cadena original y traducción, luego, crear otra columna en la que se inserte la diferencia del recuento de caracteres entre original y traducción y, finalmente, en función del resultado obtenido, indicar mediante un mensaje si las cadenas son válidas o no válidas.

Para los que queráis crear un recurso de este tipo, que también puede resultar adecuado para textos audiovisuales, ahí van los pasos detallados (al final del post facilito un modelo ya completo).

  1. Creamos la hoja de Excel con las columnas (campos) indicadas anteriormente. Una vez completado este paso, vamos a insertar la fórmula de recuento en la 3ª y 4ª columna para el recuento de cadena original y traducida respectivamente. Para ello, seleccionamos la tercera columna, en la segunda fila, y pulsamos el botón de fórmula o función (fx) y, entre las categorías disponibles, escogemos Texto y la función Largo. Para la cadena original, seleccionamos la fila A2, mientras que, al repetir la operación para la traducida, seleccionamos la B2, como se muestra en la ilustración.
  2. Automáticamente, se insertarán los recuentos. A continuación, vamos a trabajar en la diferencia. Para ello, en la columna de la diferencia, señalamos la fila 2 (E2) y, a continuación, en el cuadro de la función, escribimos =D2-C2 (es decir, que ponga el resultado de restar C2, caracteres originales, a D2, caracteres de la traducción). De esta forma, ya tenemos un resultado: si el recuento es positivo, nos hemos pasado la restricción, si no, correcto.
  3. Por último, para que tengamos esta información sobre el estado de la restricción más clara, vamos a poner una función condicional en la última columna. Señalamos la fila F2 e insertamos una función. Seleccionamos la categoría Lógica y, a continuación, SI. Finalmente ponemos como valores lo siguiente: D2 <= C2 (en Prueba_lógica), CORRECTO (en Valor si verdadero) y ERROR (en Valor si falso). De esta forma, si la traducción es más larga que la cadena original, es estado indicado será Correcto, mientras que si se supera la restricción de caracteres el resultado será Error.
  4. Como podéis ver, el resultado es bastante bueno.

Como todos sabéis, en el mundo de la traducción y la localización profesional, el escenario no es siempre el ideal y, a menudo, somos nosotros los que tenemos que ingeniárnoslas para salir del paso airosos y realizar una labor de calidad. Muchas veces resulta mucho más práctico optar por soluciones sencillas y rápidas como, por ejemplo, este Excel de recuento de caracteres que por otras más complejas (como habría sido pasar el texto entregado en SDLX a Passolo o Alchemy Catalyst, sobre todo porque esta tarea no estaba pagada y podría resultar incómoda al revertir el proceso para la entrega).

Espero que este post os resulte útil y que especialmente os sirva para que vosotros desarrolléis más ideas sencillas y directas. Por cierto si alguien quiera el comparador de Excel, que lo descargue de mi web a través de ESTE ENLACE.

Un saludo a todos. Atentamente,

Álvaro

Recomendación musical: Beady Eye, The Morning Son. Todavía no tenemos vídeo original, pero algo es algo