Añadir términos a una base terminológica (TB)

Introducción

Algunos clientes tienen una terminología específica que se debe usar en sus encargos. La recogemos en las bases terminológicas o termbases (TB). Estos glosarios normalmente estarán disponibles en formato compatible para Trados (.sdltb) y para MemoQ (que será un archivo .mtb más una serie de archivos .mtx o, como alternativa, en Excel, que el traductor podrá abrir sin mayor dificultad). En PM interactuamos con las TBs de dos maneras principalmente:

• cuando la cargamos en Xbench para nuestro control de calidad veremos los resultados que arroja Xbench si detecta alguna inconsistencia con las preferencias registradas en la TB.
• para consultar la TB o buscar cualquier entrada en particular, podemos abrirla directamente en formato .sdltb usando el programa Multiterm.

Es tarea de todas las PMs de cada equipo actualizar las TBs existentes de sus clientes (o incluso crear nuevas TBs cuando surja la necesidad). El mantenimiento en sí y el proceso de actualización o creación de esas TBs es tarea de JMM bajo petición de las PMs.

Cuándo actualizar una TB

Normalmente, el contexto más frecuente en el que surgirán términos relevantes para la TB de un cliente será a lo largo de nuestros proyectos. Podría ocurrir que los traductores tengan dudas sobre cierta terminología compleja (una vez atendida la duda e incluso entregado el trabajo, podría interesar añadir esos términos a la TB del cliente). Podría ser que, durante el control de calidad, la PM identifique términos clave que considere relevantes. Como hemos dicho, el proceso de actualización de una TB ha de surgir por iniciativa propia, pero es en beneficio de todo el equipo.

Por supuesto, también pueden surgir nuevos términos que añadir a petición del cliente, o bien petición directa, o bien a raíz de traducciones nuestras que el cliente nos envíe revisadas con algún cambio. Si dentro de sus correcciones identificamos términos clave, les indicaremos esas preferencias terminológicas que hemos detectado en sus correcciones y les preguntaremos si quieren considerar esas correcciones como algo puntual para ese proyecto o si querrían que las añadamos a la TB y se usen siempre en el futuro (les ofreceremos esto solamente para términos clave, y solamente si, una vez consultados nuestros traductores, confirman que les parece correcto y aceptarían usar esa traducción en el futuro).

Por supuesto, solo añadiremos términos a una TB si tenemos su traducción validada por un traductor (o por el cliente) y, como decíamos, solo añadiremos términos clave (relevantes en el campo de ese cliente, conceptos técnicos, no ordinarios, términos que no varíen según el contexto, etc.).

Esto último es fundamental para no contaminar la TB. También es importante el modo exacto en que añadiremos los términos, pero eso lo veremos más adelante.

Cuando añadimos un término, será a raíz de un determinado encargo (en una determinada dirección, ej. EN>ES), pero pensemos que las TBs son multidireccionales, multiidioma. Lo que se añada de un idioma A a un idioma B, lo verá también el traductor que trabaje del idioma B al A, y se guiará por esa sugerencia de la TB. Esto implica que debemos añadir información que sea válida entre todos los idiomas que añadamos en esa entrada. En casos excepcionales que no sea así, debemos añadir una nota, indicando “only for A>B translations”, por ejemplo.

Cómo actualizar una TB

La PM le enviará a JMM la información que hay que añadir o modificar en un correo, poniendo en copia al departamento pertinente.

Para hacerlo tenemos dos alternativas:

• Si son un par de términos solamente, podemos explicarlo en el cuerpo del correo de la manera más clara posible para JMM. Veamos un par de ejemplos:
  • Si necesitamos crear una nueva entrada:

idioma 1 → término

idioma 2 → término (+ nota: xxxxx)

idioma 3 → término

…

• • Si es un cambio en una entrada existente, decir qué idioma es el que hay que cambiar, describir cómo aparece ahora y cómo necesitamos que quede.
• Si tenemos varios cambios/nuevas entradas, será más cómodo para él que le enviemos un Excel con varias columnas.

A continuación, algunas instrucciones que JMM nos ha solicitado seguir:

• Crear una columna por idioma, indicando la variante si fuese relevante.
  • (ejemplos sin variante) DE, FR, etc.
  • (ejemplos con variante) PT-pt, PT-br, ES-mx, etc.
• Si hubiese que añadir notas en alguna entrada (o modificar las notas existentes), las ponemos en una columna llamada Notes situada a la derecha del idioma al que aplicará la nota. Así las identifica fácilmente y las puede incluir más fácilmente si desde el Excel hace una importación de todos o parte de los términos en Multiterm.

• En casos puntuales podríamos querer registrar varias opciones porque el cliente acepte todas ellas. Poner los sinónimos separados de una raya vertical (|) (sin espacio delante o detrás de la barra) en lugar de uno por línea dentro de la misma celda ya que, si JMM usa las opciones de importación semiautomáticas para volcar los términos del Excel a Multiterm, se considerarán términos distintos (se crearán distintas entradas) y no uno solo como pretendemos. Además, se le podría escapar algún término si no aumenta el tamaño de la fila o le podría resultar confuso en idiomas que desconozca. Veamos un ejemplo de cómo registrar sinónimos:

• Si queremos registrar un término como prohibido, lo indicaremos en rojo.

Aquí vemos una entrada en Multiterm con un término prohibido:

Aquí vemos cómo se enviaría la información a JMM para crear esta entrada:

ATENCIÓN: cuando añadimos un término prohibido a una base terminológica normalmente lo hacemos basándonos en una combinación de idiomas específica. Sin embargo, las bases funcionan de manera multilingüe. Podría ocurrir que un término que esté prohibido en traducciones a determinado idioma aparezca en textos donde ese idioma es el idioma original. Podríamos necesitar añadir a la base terminológica equivalentes en otros idiomas para ese término prohibido, para cuando aparece en los originales. Para evitar resultados confusos en nuestros QA en el futuro (en función de la combinación de idioma), conviene añadir una entrada nueva; no usar la entrada en la que aparece como prohibido. Ejemplo:

La entrada previa (la del término prohibido) funcionará correctamente para garantizar que, en proyectos IT>ES, no se utilice el término prohibido. Sin embargo, la segunda entrada nos sugerirá la opción correcta en proyectos ES>XX.

Consejos adicionales

Trados reconoce en nuestros textos los términos clave que podamos haber añadido al glosario incluso aunque presenten pequeñas variaciones (por defecto, reconoce un 70% o más de similitud), por lo que normalmente reconocerá las formas en plural e incluso los cambios en las palabras por masculino/femenino o minúscula/mayúscula.

Por lo tanto, debemos evitar registrar los términos de dos formas distintas, ni en distintas entradas ni con las dos formas dentro de la misma entrada. Registraremos todos los términos de un único modo, el más genérico posible: minúscula, masculino, singular.

Es decir:

• Evitaremos incluir distintas combinaciones de mayúsculas. Solo la que consideremos más frecuente en ese término:

NO: INE Transducer array|INE Transducer Array

SÍ: INE Transducer Array

NO: Comité de Ética|Comité de ética

SÍ: Comité de ética

• Evitaremos registrar el término con diversas posibilidades:

NO: dispositivo|dispositivos

SÍ: dispositivo

NO: device|devices

SÍ: device

Registrar los términos de distintas formas es contraproducente porque Studio mostrará todas esas sugerencias a los traductores, lo que puede resultar confuso, y también puede generar “ruido” con falsos errores en nuestro control de calidad con Xbench.

IMPORTANTE: Excepcionalmente se añadirán los términos en femenino, en plural o con alguna mayúscula cuando realmente ese sea el modo más frecuente en que encontraremos ese término.

• Cuando a un término se le asocie una sigla, crearemos una entrada distinta para la sigla, por un lado, y para la forma desarrollada (sin sigla), por otro.

Si se fusionan en una única entrada, nos puede generar falsos errores/dar sugerencias erróneas en nuestro control de calidad en Xbench, ya que en el día a día, dentro de los textos que traducimos podrá aparecer a menudo solo la sigla, solo el término desarrollado, también la unión de ambos… Registrarlos en el glosario de manera independiente permite el correcto funcionamiento de la TB, tanto en Trados a la hora de sugerir la traducción a los traductores como en Xbench durante el control de calidad de las PMs.

¿Qué pasa si en un texto nos encontramos justo con la forma desarrollada seguida de la sigla?

Studio reconocerá ambos elementos por separado dentro de esa frase y le mostrará al traductor la sugerencia tanto de la forma desarrollada (solo) como de la sigla, y lo mismo en nuestro control de calidad. Valorará ambos elementos por separado y nos advertirá si falla alguno de ellos.

(De todas formas, ni registrando las siglas del modo más normativo posible evitaremos del todo los falsos positivos en Xbench, ya que hay algunos flecos sueltos en la configuración de términos tan cortos dentro de las TBs, pero sí se reducirán al mínimo.)

La traducción de siglas es particularmente compleja, así que son elementos que nos interesa especialmente añadir a nuestras TBs para garantizar que se traduzcan siempre igual. De lo contrario, es frecuente que cada traductor tenga una preferencia distinta a la hora de traducirlas. No solo que cada traductor opte por distintas formas de traducir una misma sigla sino que cada traductor opine de distinta forma respecto a traducir la sigla o dejarla igual que en el original (esto último puede depender de la preferencia personal del traductor o incluso preferencias del cliente). Sea como sea, una vez entregada una traducción donde se han tomado determinadas decisiones para la traducción de las siglas, es muy recomendable añadirlas a la TB para asegurarnos de que en futuros encargos se traduzcan del mismo modo.

Además de esa finalidad de buscar la consistencia, hay otra cuestión. En el punto anterior tenemos el ejemplo de ICF, que es una de las siglas más habituales en el ámbito médico, y un traductor especializado no tendría dudas respecto a su significado. Sin embargo, en el día a día, traducimos textos con otras siglas mucho menos conocidas.

Es muy habitual que un traductor tenga dudas sobre el significado de una sigla, o incluso que le asigne un significado que no es el correcto y, por ende, traduzca mal la sigla. Para evitar esto, es muy recomendable que, cuando agreguemos siglas a la TB, añadamos una breve explicación de la misma en el apartado Notas, para que Studio muestre esa información al traductor cuando se encuentre con esa sigla. La mejor explicación puede ser precisamente la forma desarrollada de la sigla.

A la hora de agregar una sigla a la TB, lo normal es que lo enfoquemos de manera unidireccional (“ha aparecido esta sigla en mi encargo EN-ES y la voy a añadir por si aparece en el futuro”). En este caso, podríamos pensar que la nota sobre la sigla es relevante solo en inglés, para que le sea de ayuda al traductor español en el futuro, pero pensemos que las TBs son multidireccionales, así que no está de más añadir las aclaraciones en todos los idiomas involucrados.

En relación con esto, también cabe mencionar que no es extraño encontrar siglas que puedan tener distintos significados, por lo que habrá que matizar qué posibles significados tiene y de qué manera se debe traducir dependiendo del significado exacto. En estos casos, debemos crear dos entradas independientes, una por significado. A JMM se lo enviaríamos así:

Configuración importante en Trados

Mostrar notas y términos prohibidos (y otros ajustes de visualización)

Hay un par de cuestiones que es importante que conozcamos o incluso compartirlo con los traductores, porque de una correcta configuración dependerá en gran medida obtener traducciones correctas.

Si bien nuestro control de calidad en Xbench nos advertirá de posibles errores en la terminología, será más útil que los traductores ya visualicen la información de la TB del modo más completo e intuitivo posible dentro de Trados. Las notas y los términos que registramos como prohibidos dentro de las TBs no se muestran en Trados de manera predeterminada mientras se traduce. Es cada usuario (traductores, PMs) quien debe configurarlo en Trados, para que se muestre esa información en la ventana de resultados de la TB.

Desde un proyecto donde tengamos la TB en cuestión cargada y operando, (1) pulsamos Configuración de lista de aciertos (Hitlist settings en inglés), donde tenemos varios ajustes que pueden ser interesantes.

(2) De entrada, para configurar los campos adicionales que queremos mostrar, iremos a Seleccionar campos (Select fields) y se abre la ventana (3) donde marcaremos los campos que necesitemos, que pueden variar según la TB. En este caso, tenemos tres posibles campos. Notes mostrará las notas y Status mostrará los prohibidos. Es recomendable marcarlos tanto en source como en target, ya que a veces habrá notas en idioma source que puedan ser relevantes. Si no queremos configurar más que esto, daremos a Aceptar y quedará debidamente configurado. Veamos algunos ajustes secundarios:

(4) Según si se tiene Campos compactos (Compact fields) marcado, o si se desmarca y se marca Ampliar campos (Expand fields), veremos la información de los resultados de la TB más o menos compacta. Podemos ver justo a la derecha de esas opciones una previsualización de cómo quedaría cada caso.

(5) En Fuente (Font) se puede cambiar la fuente, tamaño, el color, etc. de los campos.

(6) También podemos modificar ajustes no relativos a los campos adicionales sino a los propios términos, las sugerencias de la TB, en Fuente de origen/Fuente de destino (Source Font/Target Font).

Verificación de terminología

También puede ser interesante que los traductores conozcan cómo configurar en Trados un par de ajustes básicos de verificación de terminología.

(1-2) En Configuración de proyecto > Verificación > Verificador de terminología > Configuración de verificación (Project Settings > Verification > Terminology Verifier > Verification settings) se abre una ventana donde principalmente interesará marcar 3 aspectos: las dos primeras casillas de verificación, para que Trados de un aviso de error si en el segmento de destino no encuentra la sugerencia de la TB o si se usa un término registrado como prohibido, e indicarle que los términos prohibidos son los que están registrados con status forbidden.

---

Recuerda que todas estas instrucciones son una guía y, dependiendo de cada caso y de cada cliente, podemos ajustarlas para cubrir nuestras necesidades. Al fin y al cabo, estos glosarios son una herramienta interna para facilitarnos nuestro día a día y mantener la coherencia terminológica en nuestras traducciones. También, en caso de duda, consultemos a JMM.