PSI

Descripción

Este manual reúne toda la información relativa a los procedimientos acordados para los proyectos de nuestro cliente PSI.

En la carpeta del cliente en Plunet (perfil 1392 en Plunet) se almacenan algunos correos electrónicos relevantes intercambiados con ellos, por si en algún momento se necesita consultar el origen de cualquier indicación recogida en este manual.

Este manual comprende los siguientes clientes en Plunet:

• PSI-EUR: 1392
• PSI-USD: 2951
• PSI-Taiwan: 3173

Y en definitiva, todos los clientes que forman parte del grupo PSI, en caso de que se amplíen posteriormente.

Desde marzo de 2023, todo se presupuesta y factura a nombre del cliente PSI-EUR (1392), en divisa EUR, excepto:

• los trabajos que involucran ES-US como idioma origen o destino, que se harán a nombre del cliente PSI-USD, en divisa USD. Para adaptaciones, consultar al cliente, porque dependerá de dónde vayan a usar la adaptación;
• proyectos para PSI-Taiwan, que se presupuestarán y facturarán a nombre de dicho cliente.

El perfil que consideramos principal, cuyo memo/carpeta de cliente se mantienen actualizados, es PSI-EUR.

Información general

Introducción al cliente

PSI es una Organización de Investigación por Contrato (CRO, por sus siglas en inglés), una compañía que ofrece servicios integrales de investigación clínica y asesoramiento en el desarrollo de ensayos de investigación en una variedad de áreas como la oncología, hematología, enfermedades intestinales e infecciosas, entre otras.

Nos derivan proyectos de diferentes promotores y ensayos clínicos. Cada proyecto se registra en nuestro sistema de gestión con su correspondiente código de protocolo.

Personas de contacto

Para procedimientos generales y administrativos relativos a todo PSI, la persona de contacto es VP.

Las personas de contacto para temas relacionados con proyectos de trabajo dependen de los países/idiomas de destino:

• Portugal, Brasil, USA (también ES-US): VP
• España + variantes LatAm: AI

En ambos casos, existen otros interlocutores apoyando a cada equipo. En nuestras comunicaciones por email con ellos, pondremos en copia siempre al email del grupo «Translations Spain». (Lo suelen hacer ellos al escribirnos).

• Thai: EP
• Alemania: LM

En estos casos no se pone en copia a «Translations Spain». En el caso de thai, normalmente irá en copia «Translations Thailand», y en el caso de proyectos que impliquen alemán, «Translations Dach».

En estos dos equipos a veces copian a otros grupos, así que no debemos agregar nosotros sus direcciones de email grupales habituales, por si acaso. Normalmente ya habrán añadido ellos las direcciones relevantes cuando nos escriben. Responderemos a todos los emails con la opción de “Responder a todos”, manteniendo siempre en copia a nuestra cuenta de correo para este cliente.

• Nota 1: Las siglas de las personas de contacto pueden verse en Plunet. Son sus iniciales, pero igualmente se puede ver desplegando el contacto que intuimos, dentro del campo «Source of contact».
• Nota 2: Los emails del grupo se encuentran registrados en Plunet, como un contacto más.

Tipos de proyecto y Pricelists

Realizamos varios tipos de proyectos para PSI: traducción, revisión, adaptación, traducción directa (forward translation), back-translation…

Para proyectos de traducción, el cliente solicita por defecto realizar una revisión adicional por un segundo lingüista, así que el servicio será el de traducción + revisión. Se usará la pricelist T+R y se registra como Translation. No se añade otra partida adicional de revisión. La tarifa de traducción de la pricelist T+R del cliente ya engloba el paso de traducción y el de revisión.

Este proceso de revisión de traducciones propias se considerará para el cálculo de plazos como revisión de alta calidad, ya que es lo esperado de nuestros traductores.

Para adaptaciones y revisiones, trabajará en el texto un solo lingüista, el proceso será de un solo paso. Aunque son trabajos que facturamos por horas, se puede usar la pricelist T+R también. El precio por hora de PSI es el mismo para cualquier tipo de tarea. (No cambiamos la tarifa por hora porque haya más pasos en el encargo, sino que lo que cambia es el número de horas que requerirá el proyecto).

El cliente tiene una tarifa mínima y varias pricelists (urgentes, solo traducción) para cubrir distintas necesidades. En líneas generales, la pricelist de solo traducción la utilizamos únicamente en casos puntuales en que, por cuestiones de urgencia, principalmente, el cliente nos pide plantearnos distintas posibilidades, entre ellas, urgente o solo traducción (omitir la fase de revisión para acortar el plazo).

Como característica particular, que difiere de nuestros procedimientos generales, con PSI se ha acordado contabilizar los documentos no editables como si fueran editables. Para ello preparamos una conversión (OCR sucio) que analizamos en Trados y contabilizaremos los fuzzies como haríamos con textos editables. La edición se cobra en el presupuesto en una partida de Word(s) File Preparation. Ver el apartado «Edición de PDF».

Solicitudes idénticas a diferentes idiomas

Puesto que existen diferentes interlocutores de PSI que se ocupan de diferentes combinaciones de idiomas, es habitual recibir los mismos proyectos por parte de distintos interlocutores, para traducir a distintos idiomas de destino. En la medida de lo posible, estaremos atentas a todas las solicitudes que recibimos para poder identificar cuando un nuevo proyecto es el mismo que hemos presupuestado recientemente a otro idioma. Cuando un proyecto parta de los mismos documentos originales y tenga características idénticas, debemos seguir el mismo enfoque que se siguió en el presupuesto anterior, presupuestar los mismos pasos, proponer plazos similares (siempre según recuento), etc. Por supuesto, los recuentos por palabra dependerán de cada combinación de idiomas y cada memoria de traducción, pero en los proyectos calculados por tiempo, la estimación de tiempo sí se espera que sea la misma.

Materiales de referencia

El cliente tiene tanto memoria de traducción (TM) como base terminológica (TB) propias que habrá que utilizar tanto para las traducciones como para nuestro control de calidad:

• medical-PSI_Master
• medical_termbase_PSI-CRO

Si en la base terminológica no está incluido el idioma o la variante específica que aplica al proyecto, no será relevante utilizarla.

También hay una guía de estilo donde recopilamos las preferencias del cliente para diferentes idiomas. Está indicada por defecto en el campo correspondiente del cliente en Plunet y deberemos compartir con los lingüistas en todos los proyectos (esto ya ocurre así por defecto, a menos que por algún motivo se elimine la información de dicho campo).

Como gestoras de proyectos, es FUNDAMENTAL que consultemos la guía de estilo para familiarizarnos con los requisitos del cliente en lo relativo a aspectos específicos de trabajos, de combinaciones de idiomas, etc. y que la repasemos durante nuestro control de calidad. Cualquier nueva directriz que surja por parte del cliente y que los traductores deban considerar habrá que añadirla a la guía de estilo del cliente, que está en constante evolución. IMPORTANTE: Recordar modificar la fecha de actualización (al inicio del documento).

Además, en la carpeta Download del perfil del cliente guardaremos todo material general de referencia. Daremos acceso a los lingüistas a esa carpeta en todos los proyectos.

Variante idioma original

Nuestro procedimiento general indica que en nuestro sistema de gestión y, por lo tanto, en presupuestos y facturas, no especificaremos la variante del idioma original, solo del idioma de destino. También será la norma a seguir con PSI, salvo por los siguientes casos excepcionales donde sí especificaremos variante del idioma original. Se mencionarán también en los apartados correspondientes en este manual, pero se añade esta aclaración independiente para mayor visibilidad:

• Back-translations: en pie de página y CoT
• Adaptaciones: en Plunet (Quotes/Orders/Facturas) y CoT

Plazos

Para el cálculo de tiempos y plazos para T, T+R y cualquier otro servicio, seguiremos siempre los procedimientos generales de Gestión de Proyectos y podremos ayudarnos de las diferentes calculadoras que están disponibles en el CRM.

Este cliente acostumbra a solicitar una determinada fecha de entrega para cada solicitud, pero no siempre es un plazo suficiente bajo tarifa estándar. Además, no siempre será absolutamente prioritario para ellos cumplir con esa fecha que indican. En términos generales, PSI procura realizar todos los proyectos con tarifa estándar siempre que sea posible, así que si proponen una fecha que es inviable bajo la tarifa estándar, les enviaremos solo un presupuesto, con tarifa estándar y con el plazo estándar que veamos conveniente. No enviaremos sistemáticamente presupuesto estándar y presupuesto urgente. Solo lo haremos cuando verdaderamente den a entender que esa fecha es absolutamente necesaria o la PM considere interesante explorar ambas posibilidades ya de entrada. En todo caso, al enviar el presupuesto estándar, seamos informativos con el cliente, aclarándoles si la fecha que ellos indican se podría conseguir con tarifa urgente o ni siquiera. Situémosles en qué posibilidades tienen, aunque de entrada enviemos solo el presupuesto estándar.

En casos de verdadera urgencia o insistencia por su parte, será cuando podremos sugerirles realizar solo traducción (muy pocas veces optan por esta opción) pero, como decimos, por defecto no es necesario elaborar dos o tres versiones de presupuesto cuando la fecha de entrega sugerida sea demasiado justa, ya que la tendencia general es a adaptarse a nuestra mejor fecha de entrega estándar. Si no, ya elaboraremos las alternativas que sean convenientes.

Plunet

Hay que enviar presupuesto con cada encargo, eligiendo en Plunet el output “Default (with price memo)”.

El campo de Project name siempre debemos rellenarlo con el nombre del archivo para traducir. Cuando son varios archivos, lo haremos con todos los nombres de archivo unidos con un símbolo + (por ejemplo, Archivo 1 + Archivo 2 + Archivo 3… y así sucesivamente), no el rango de documentos (Archivo 1-Archivo 12) que aparecerá en el asunto del e-mail del cliente. No incluyamos la extensión (.docx, .pdf, etc.) del archivo cuando hagamos esto.

Al crear el item a partir del Project name, implicará que siempre dejaremos ambos campos con la misma información.

TRUCO: En proyectos con muchos documentos, aunque en Plunet no haya problema para registrarlo, en ocasiones al exportar el presupuesto este sí presenta un aspecto desbordado y no aparece bien la información de los recuentos y los costes. Cuando esto ocurra (y solamente en estos casos en que la información no se lee bien), podemos arreglarlo antes de enviarlo al cliente:

• En Plunet siempre dejaremos el listado completo de documentos tanto en Project name como en el item. Como recordatorio, el campo verdaderamente relevante de cara al cliente es el item. Es de los items de donde Plunet toma la información para las facturas.
• Podemos corregir la estructura del presupuesto, solo dentro del quote al descargarlo de Plunet en formato .rtf (Word), sustituyendo el listado completo de documentos por el rango, da igual si en el propio item o en la parte de encima. En todo caso, siempre debe constar el listado completo de documentos en uno de los dos puntos del presupuesto.

PSI sigue un sistema de trabajo que resulta muy explicativo. A cada documento que nos envían le asignan un identificador (XXXXOKD). Sabremos siempre a qué estudio/protocolo hay que asociar cada solicitud porque se indica en el asunto de sus emails, que siempre siguen una estructura similar:

8963OKD-8968OKD_MORF-057-203_Colombia_ICFs_v 1 0_EN>ES_CO

Códigos de los documentos originales, código de protocolo, descripción de los documentos, combinación de idiomas.

Siempre adjuntarán los documentos que debemos traducir o utilizar para la traducción y, si falta alguno, se lo pediremos. Cada documento vendrá nombrado con su correspondiente identificador y nombre de archivo.

Para los clientes de la rama médica en ocasiones realizamos proyectos que no se encuadran dentro de ningún estudio clínico, que no solicita ninguno de sus clientes finales sino ellos mismos. Es decir, no habrá que registrarlos bajo ningún estudio clínico, sino de otra forma. La cuenta a la que PSI imputa estos proyectos la denominan CORPORATE. Lo registraremos así (aparece en los listados donde anotamos el estudio en Plunet). En el asunto del email leeremos CORPORATE donde suelen indicar el código de protocolo.

Búsquedas

Si queremos realizar búsquedas de trabajos en Plunet (Status report > Orders), en PMM es frecuente que lo hagamos filtrando por estudios, pero también seleccionando el cliente.

En adelante, cuando las búsquedas involucren a PSI, habrá que seleccionar el grupo de clientes (customer group), para englobar las solicitudes de todos los perfiles de PSI:

Otra búsqueda frecuente que se necesitará hacer con PSI es por nombre de archivo, por ejemplo, cuando el cliente pide un certificado para un documento de un proyecto pasado o que incluso puede haber gestionado otra gestora de proyectos. En el hilo en el que nos escriba el cliente tenemos más información que nos derivará el proyecto, como el presupuesto que se les envió, pero lo más rápido es buscarlo por código de documento (en el adjunto que envíe el cliente para pedir el certificado o, si no, nos sirve uno de los que sale en el asunto del email). Una de las formas más ágiles de encontrar el proyecto en cuestión será buscar “xxxxOKD” en el filtro Item description.

Correcciones de presupuestos o proyectos

Conforme a nuestros procedimientos generales, si por cualquier motivo (error o petición adicional del cliente) hubiera que modificar un presupuesto enviado al cliente, no modificaremos directamente el presupuesto enviado, sino que le enviaremos una Correction del anterior*. Si el motivo es un cambio de nombre de archivo o algo que no afecte a los costes/plazos/condiciones del servicio, se podrá corregir directamente el enviado. Para ampliar esta información, consultar la guía de Plunet y las preguntas frecuentes de PM 37, 38 y 39 en el CRM.

*EXCEPCIÓN: La única excepción a esta norma será para los presupuestos de back-translation (BT) cuando se tengan que actualizar una vez la forward translation (FWT) está lista. Podemos modificar directamente el presupuesto enviado sin crear Correction, ya que esto es parte del procedimiento habitual con el cliente.

Entregas (medio y hora límite)

Devolvemos cada trabajo en el mismo hilo de email en que lo solicitaron (no a través de Plunet) y a todos los destinatarios en copia, haciendo «Responder a todos».

Solamente prepararemos certificado de traducción (CoT) o de otro tipo cuando lo pidan (excepción: estudios 270-301 / 270-303 y APVO101-903, para las combinaciones EN<>PT-BR siempre quieren CoT).

El final de la jornada laboral (EOB, end of business) de PSI es a las 16:00 horas CET. Aunque es habitual que nos escriban también a partir de esa hora, será la hora límite para nuestras entregas. Si para un encargo nos solicitan un determinado plazo pero sin especificar hora, lo programaremos para las 16:00 horas como máximo. Si en cualquier ocasión el plazo que nos soliciten será viable pero solo si podemos entregar al final del día, habrá que acordarlo con ellos expresamente.

Consultar aquí todos los detalles adicionales sobre el proceso de entrega.

Consideraciones específicas para las fases de presupuesto y gestión de los proyectos

En este apartado se explica cómo proceder ante distintas características que pueden tener los proyectos.

IMPORTANTE: Debido a que tienen una mayor complejidad y longitud, no se explican aquí sino en un anexo al final los siguientes tipos de proyectos:

• Trabajos de track changes
• Back-translations
• Revisión
• Adaptación
• Proyectos que implican tailandés

Y los siguientes tipos de documentos:

• Documentos para EE. UU.
• Protocolos, manuales de investigador y expedientes de medicamento en investigación
• Summary of Changes
• Anexos económicos en Excel
• Clinical Trial Agreements
• Policy Endorsements

Enfoques alternativos en proyectos de traducción por sugerencia del cliente

En ocasiones PSI nos da indicaciones de cómo quiere proceder con determinado proyecto. El caso más habitual es el de necesitar una traducción (para la que haríamos T+R) pero pedirnos que revisemos otra traducción ya existente. Suelen sugerir los enfoques alternativos para conseguir mejores plazos, costes o aprovechar traducciones existentes.

Premisas básicas

Es fácil dejarse llevar por la petición del cliente, ya que además no se percibe como una sugerencia, por lo que es importante dejar claras ciertas premisas y ejemplos prácticos para saber cuál es el mejor modo de proceder ante ciertas situaciones.

Tiempo de File preparation y cálculo de tiempo de revisión

Es frecuente que analizar el proceso “alternativo” lleve más tiempo que organizarlo para traducción, revisión o lo que corresponda de manera habitual, por lo que añadiremos en el presupuesto el tiempo “extra” de gestión. PSI ha pedido que, antes de preparar el presupuesto e incluso de dedicarle tiempo a analizar el enfoque “alternativo”, les avisemos cuando algún proceso o alguna petición suya implique costes adicionales, para que valoren si les interesa lo suficiente o no (podría ser que nos ayuden con cualquier tarea que esté en su mano, por ejemplo, preparando comparaciones entre documentos). Si dan el visto bueno al tiempo “extra”, entonces procederemos a analizar el enfoque que sea y añadiremos en el presupuesto el tiempo que requiera analizar el proyecto/preparar los documentos/cualquier preparación necesaria durante el control de calidad, en una partida de Hour(s) File Preparation, redondeando al alza por medias horas (la primera media hora también se presupuesta).

El tiempo de esta partida dependerá exclusivamente de cada proyecto. El único proceso que hemos calculado para homogeneizar es cuando tenemos varios documentos originales que “traducir” usando diferentes documentos target, es decir, que habrá que duplicar traducciones y reutilizarlas. Al tiempo que nos lleve analizar el proyecto, realizar comparaciones (si procede), etc., y además, podemos añadir 2 minutos por cada documento original de la solicitud, para compensar lo que se tarda en hacer una copia de la traducción que habrá que reutilizar y cambiar el filename y el footer como corresponda según su original.

NOTA: Si la PM enviará un presupuesto con el proceso habitual para ese tipo de proyecto y otro con el proceso que sugiere el cliente por abaratar costes, el tiempo de File preparation se aplicará únicamente en el segundo presupuesto (incluso aunque acaben aprobando el primero).

También, cuando realicemos revisión de traducciones similares para obtener otras traducciones, este proceso no se trata de una revisión habitual, sino que se espera que haya diferencias de contenido más significativas, por lo que según la similitud que detecte la PM, podrá calcular el tiempo de revisión usando la ratio de revisión de CTA. Como en toda revisión, se calculará en base al recuento de los originales, si los tenemos (si son PDF, de su OCR).

• IMPORTANTE SOBRE REVISIÓN: Solamente aceptemos trabajar en el proyecto bajo el enfoque de revisión si la PM valora que original y traducción tienen un alto grado de similitud, sobre todo a nivel estructural, de formato. Si no, se les indicará que lo conveniente es traducir el documento original desde cero.
• Ante cualquier sugerencia del cliente, lo fundamental es entender qué necesitan y “olvidarnos” del proceso que sugieren. La PM conoce los distintos procesos y sus implicaciones mejor que el cliente. Cuando la PM vea claro qué resultado se necesita, qué proceso es el mejor y cómo es justo presupuestarlo, responderá al cliente con el presupuesto ya preparado y las explicaciones pertinentes, en lugar de consultarles de antemano e iniciar un debate a menudo innecesario. Es importante tener una actitud explicativa y orientadora, además de eficaz.
• La PM ofrecerá al cliente solamente la opción que considera más adecuada. Únicamente se le enviarán diferentes opciones cuando verdaderamente sean igual de aconsejables y queramos dejar al cliente decidir qué prefiere.
• La PM analizará los costes y plazos tanto del enfoque que sugiere el cliente como del que considera más adecuado en cuanto a productividad y costes (o más posibles enfoques si lo ve conveniente).
  • Si el proceso que sugiere el cliente es sustancialmente más conveniente para el cliente (a nivel de costes o plazos), se presupuestará, siempre y cuando la PM valore que es un proceso razonable.
  • Si, por un importe similar o ligeramente superior (a valorar por la PM), es mucho más productivo o seguro realizar el proceso habitual para ese tipo de proyecto (o cualquier otro proceso que considere la PM), se presupuestará este, explicándole al cliente los motivos y que el coste es muy similar.
• No es necesario que sea el cliente quien proponga ciertos procesos menos habituales. Por defecto, cada PM será proactiva a la hora de guiar al cliente hacia el proceso más conveniente para cada proyecto, siempre dentro de las indicaciones de este manual o consultando con un supervisor ante circunstancias más excepcionales. Ejemplos:
  • Si quieren conseguir una traducción revisando una traducción anterior muy voluminosa, podemos explicar al cliente que al traducir en Trados, ya nos aparecerán todas las coincidencias parciales y totales con traducciones anteriores, es decir, ya se revisará ahí, bajo un proceso mucho más productivo y que nos permite mayores controles de calidad. Se les envía ese presupuesto. Si insisten por motivos de costes, incluso se podría ofrecer bloquear 100% matches/repeticiones, si la PM considera que eso seguiría siendo más eficaz que revisar la traducción entera. En esta opción alternativa, añadiremos al presupuesto el tiempo estimado para este proceso (fase previa de bloquear segmentos y posterior, de pretraducción y revisión).
  • Si simplemente piden el enfoque habitual de traducción desde cero de varios documentos y la PM detecta que son muy similares entre sí, demostrará profesionalidad si sale de ella sugerir traducir solo uno de los archivos (si hay uno que tenga más contenido que otros, el más voluminoso) y obtener el resto de traducciones reutilizando esa traducción una vez esté lista (ver abajo ejemplo práctico). Al cliente no le daremos más detalles que esa explicación anterior, pero a la hora de valorar el proceso interno, la PM tiene total libertad para enfocarlo como vea más sencillo, por ejemplo, en este caso podría ser relevante realizarlo como un proyecto de track changes (más abajo se desarrolla este ejemplo práctico).
• Cada PM tiene la libertad de organizar, de manera interna, estos proyectos “alternativos” del modo que considere más sencillo para ella/para el traductor/revisor, aunque no necesariamente se alinee con lo mencionado en el presupuesto: comparación con Draftable, comparación automática en Word de OCRs sucios, enviar al traductor solo uno de los documentos y obtener la PM el resto a partir de esa traducción… lo que resulte más sencillo o rápido (que no siempre será enviarle todo al traductor e invertir demasiado tiempo en explicaciones).

IMPORTANTE

Algunos de estos procesos “alternativos” se han convertido ya en algo frecuente, pero en el día a día surgen otras peticiones que quizás aceptaremos hacer, pero de manera puntual. En esos casos, dejemos claro su carácter excepcional.

Además, cuando realizamos alguna excepción al procedimiento, no es raro que en el futuro nos lo vuelvan a pedir. Es por eso que tenemos que valorar con mucho detenimiento todo aquello que se salga de la norma, porque puede tener implicaciones futuras para todo el equipo. Por ese motivo, consulta siempre con un supervisor antes de proceder con una petición por parte del cliente/una iniciativa propia de la PM/un procedimiento que se salga de lo pautado en este manual, para obtener una segunda opinión.

Ejemplos prácticos

Ejemplos de procesos “alternativos” más habituales:

Documentos similares: Traducción de un documento + TC/revisión para obtener la traducción del resto

• Situación 1: El cliente necesita traducir un nuevo documento y nos manda una traducción previa similar/nos menciona otro proyecto anterior donde se tradujo un documento similar. Podemos valorar la similitud y usar la traducción previa para obtener la(s) nueva(s).
• Situación 2: Nos envían para traducir varios documentos administrativos que son muy similares entre sí. Ej. pólizas de seguros. Para la mayoría de ellas que consideremos muy similares, se podrán seguir los procesos explicados a continuación, pero para un tipo específico que conocemos como policy endorsements se ha definido un proceso específico.

ATENCIÓN: si cualquiera de los documentos tiene un formato muy diferente, evitaremos cualquier proceso de revisión/actualización, ya que implicaría mucho tiempo y esfuerzo. Solamente haremos T+R desde cero.

• Documentos muy cortos: si son extremadamente similares, lo más eficaz es traducir uno y revisar el resto. Si no son tan similares, no será relevante entrar en procesos alternativos, sino seguir el proceso habitual de T+R de todos los archivos (las similitudes/repeticiones ya se aprovechan en Trados y se reflejan en el presupuesto, y el proceso es más eficaz y seguro).
• Documentos largos: ver a continuación en función del formato.

Documentos Word

Proceso

Identificamos cuál es el documento original más largo o completo (en igualdad de condiciones, uno cualquiera). Valoraremos si se puede traducir solo ese y obtener el resto de traducciones a partir de esa. Si el resto de documentos son cortos, quizás es más eficaz enfocarlo como revisión. Si son largos, no es eficaz organizar muchas horas de revisión, así que antes compararemos los documentos y, en función del número de cambios, podría interesar enfocarlo como un proyecto de track changes. Comparamos el original que pretendemos traducir con el resto de originales de la solicitud, uno a uno, y guardamos el documento con los cambios marcados que habría que implementar en la traducción del primer documento una vez la tengamos. Se traduce el primer documento y se obtienen las demás traducciones haciendo copias de la primera traducción y actualizándolas con los cambios que requiera para hacerla coincidir 100% con cada uno de los demás documentos originales de la solicitud.

Presupuesto

Se explicará al cliente exactamente cómo vemos más conveniente enfocarlo. Se presupuesta T+R de un documento, por palabras, y la del resto en Hour(s) Review, si se plantea hacer revisión, o Hour(s) Translation, si se plantea hacer comparaciones e implementar cambios. (Ver notas sobre tiempo de File Preparation y cálculo de tiempo de revisión aquí).

Traductor/revisor/QA

Explicaremos al traductor/revisor exactamente lo que necesitamos que haga, en función del proceso y, si es track changes, les enviaremos las comparaciones que hemos obtenido.

Aunque el proceso sea distinto al habitual, el resultado/la necesidad del cliente es una traducción normal, así que como siempre, renombraremos cada traducción y añadiremos el PSI-footer en base a su correspondiente original, y se entregarán las traducciones sin cambios marcados. Si piden certificado de los documentos, será de traducción.

Documentos PDF

Proceso

El mismo proceso se puede hacer también con PDF. De manera interna, podemos comparar los OCR sucios que obtengamos (si la calidad es mala, podrán salir más cambios de los que realmente hay) o comparar los PDF usando Draftable pero nunca diremos al cliente que es posible comparar documentos no editables (documentos Word sí).

Presupuesto

De cara al cliente, los documentos PDF solo se pueden comparar a ojo (lo que no es fiable), por lo que no ofreceremos en ningún caso track changes sino revisión. Hay dos opciones:

• editar y traducir+revisar solo un documento y obtener el resto de traducciones revisando esa primera contra el resto de originales. Se presupuesta File preparation y T+R de un solo documento + la revisión del resto como Hour(s) Review. (Ver notas sobre tiempo de File Preparation y cálculo de tiempo de revisión aquí).

O bien…

• realizar la edición, traducción y revisión de todos los documentos (proceso estándar) excluyendo del proyecto las repeticiones. (Ver notas sobre tiempo de File Preparation aquí).

Traductor/revisor/QA

Incluso aunque emitamos un presupuesto de revisión, si comparamos los documentos y consideramos que es más relevante enfocarlo como un proyecto de track changes. Podemos comparar los archivos en Draftable (la web ofrece una opción de descargar la comparación en un formato muy similar al del Word, que servirá para el traductor) o comparar con Word los OCR sucios (ya que no editaremos los PDF). Al comparar OCRs, es probable que salgan algunos “falsos TC” por cuestiones de formato o diferencias irrelevantes entre los documentos, así que podemos aclararle al traductor que no se preocupe más que por los cambios de contenido y que revisaremos bien el formato de cada documento en nuestro control de calidad.

Aunque el proceso sea distinto al habitual, el resultado/la necesidad del cliente es una traducción normal, así que como siempre, renombraremos cada traducción y añadiremos el PSI-footer en base a su correspondiente original, y se entregarán las traducciones sin cambios marcados. Si piden certificado de los documentos, será de traducción.

Excluir repeticiones o/y 100% matches

Ver apartado «Proyectos donde piden no contabilizar repeticiones o/y 100% matches».

Información confidencial o texto oculto

En ocasiones recibimos medical reports de pacientes para traducir. Suelen capar la información confidencial o que identifique al paciente antes de enviarnos estos documentos para traducir. Si por casualidad encontramos alguna información que se pueda considerar confidencial, hay notificarlo al cliente antes de presupuestar.

También nos han pedido que, si vemos texto oculto en cualquier documento para traducir que nos envíen en Word (lo identificaremos por el subrayado característico), antes de seguir, les avisemos y preguntemos si hay que traducirlo.

Archivos no editables

En este cliente se contabilizan los fuzzies incluso en documentos no editables. Preparamos una conversión y analizamos ese OCR sucio en Trados. En su pricelist tienen una tarifa por palabra para File preparation, así que en los presupuestos cargaremos el report del análisis de los archivos * y, a continuación, añadiremos una línea con el total de palabras de todos los archivos en concepto File Preparation.

*Nota: Si no conseguimos que en el OCR aparezca editable algún texto, lo contaremos a mano y añadiremos las palabras en la línea de New Words.

Aunque pueda haber partes de texto que no haya que traducir, por el motivo que sea, y que haya que excluir del análisis/recuento para traducción, File preparation debe comprender el total de palabras de todos los documentos, ya que editarse se editan enteros. Ver apartado «Texto que no requiere traducción».

Medical licenses/credentials

Este tipo de documentos implican un esfuerzo y coste de edición superior al habitual, por lo que no los cobramos por palabra (en la partida de File Preparation) sino como Hour(s) File Preparation. Si la solicitud comprende credentials y otros tipos de documentos, se cotizará la edición de los primeros por horas y el resto por palabras.

Cálculo para el presupuesto: 10 min por documento (redondeamos el tiempo al alza, mínimo media hora). Cuando el proyecto incluya varios documentos y solo 1 o 2 sean credentials (menos de media hora de edición), no será necesario cotizarlos por hora, los incluiremos en la partida habitual de File Preparation por palabras.

En el apartado «Edición de PDF» se detallan las directrices para el proceso de edición.

Preparaciones especiales de archivos editables

En ocasiones recibimos documentos Word para traducir que requieren alguna preparación adicional para entregar la traducción al cliente tal y como la necesitan; por ejemplo, traducciones bilingües a doble columna. Son preparaciones que podemos hacer antes de traducir o cuando ya tenemos la traducción.

Considerando que este cliente aprueba la inmensa mayoría de los presupuestos, es recomendable preparar el archivo antes del presupuesto, ya que de ese modo sabremos cuánto tiempo nos lleva, y lo incluiremos en el presupuesto como Hour(s) File preparation. Hasta media hora de trabajo (incluida), no se presupuestará aparte.

Preparaciones a doble columna

Al copiar el texto original en la columna de destino es frecuente que la numeración automática de los listados salga incorrecta y habrá que corregirla, o bien caso a caso o por apartados, con la ayuda de estas directrices.

En caso de falta de tiempo en la fase inicial (o que el cliente lo solicite una vez hemos comenzado la traducción), se podrá preparar al final. Podemos incluso externalizar este proceso. Habría que consultarle a la empresa de edición el tiempo estimado/el plazo que necesitarían.

Preparaciones de Excels bilingües

Se explica en detalle cómo presupuestar y enfocar esos proyectos en el apartado «Anexos económicos en Excel».

Texto que no requiere traducción

A menudo los documentos para traducir contienen texto no traducible: ya en idioma de destino o en idioma original + idioma de destino. O incluso el cliente podría pedir no traducir alguna sección, pero en cualquier caso sí tendremos que incluirla (sin traducir) dentro de la traducción que enviemos. Planteamos los siguientes escenarios para esas partes que no hay que traducir:

• Archivo editable
  • Ocultaremos en Word/bloquearemos en Trados esas partes y no se incluirán en el recuento para el presupuesto.
• Archivo no editable
  • Sí incluiremos el recuento de esas partes como File preparation (porque editaremos el documento entero), pero no las contabilizaremos como palabras para traducir. Para obtener el recuento para traducción, analizaremos una copia del OCR donde habremos borrado previamente las partes que no hay que traducir. Para obtener el recuento de File preparation, contabilizaremos el total de palabras (real, no de la copia donde hemos borrado las partes que no hay que traducir).

Documentos originales con comentarios del cliente

En trabajos de revisión o de track changes, no afecta si los documentos enviados por el cliente tienen comentarios, puesto que se trabaja sobre los archivos de destino.

En traducciones “habituales” en las que entregamos la traducción únicamente en idioma de destino, lo más frecuente es que no necesiten que dichos comentarios aparezcan (ni traducidos ni sin traducir) dentro de nuestra traducción, pero debemos confirmarlo siempre con el cliente en la fase de elaboración del presupuesto.

En traducciones que entregamos en formato bilingüe (a doble columna source-target), si el original tiene comentarios, necesitarán siempre que en el documento con la traducción consten esos mismos comentarios (sin traducir, a menos que puntualmente digan otra cosa) en la columna source.

Para conseguir eso, hay que configurar Trados de determinada manera antes de analizar el archivo para traducir. Ver curso en Okodemy «Cómo tratar los archivos docx de origen que tienen comentarios en Studio«.

Atención: para no traducir los comentarios, recordemos bloquear esos segmentos.

Documentos con imágenes

En el curso en Okodemy “Ejemplo – Edición de imágenes dentro de encargos de traducción” tenemos información general sobre cómo proceder con imágenes para clientes médicos, pero con PSI solemos proceder de un modo algo distinto en algunos casos.

En la sección correspondiente de track changes veremos indicaciones adicionales enfocadas a ese tipo de proyectos.

En documentos más divulgativos/marketing, cortos, con pocas imágenes, traduciremos y maquetaremos las imágenes no editables (proceso: extraer el texto en formato tabla ya desde la fase del presupuesto, para poder analizarlo para el presupuesto, traducirlo y maquetar las imágenes). También se puede consultar con el cliente cómo prefieren.

Sin embargo, la mayor parte de los documentos que recibimos con imágenes son documentos de gran envergadura o/y con numerosas imágenes, como protocolos, Investigator’s Brochures (IBs) o Investigational Medicinal Product Dossiers (IMPDs). Además, son tipos de documentos muy susceptibles a pasar por enmiendas posteriores, es decir, a que haya que actualizarlos con control de cambios. En estos casos, las imágenes se hacen editables dentro del documento original (con cuadros de texto) antes de sacarlo a traducir.

El cálculo del tiempo para la edición de imágenes se realiza en base a los procedimientos generales de la empresa, tiempo que se incluirá en el presupuesto en una partida de Hour(s) File Preparation (valoremos no presupuestar esto cuando el volumen del encargo sea alto y solo haya 1 o 2 imágenes). Además de la partida de File preparation en sí, también se incluirá dentro del recuento de palabras de traducción las palabras dentro de las imágenes. Obtenemos un OCR de las imágenes para poder analizar su contenido o, si son pocas palabras, se pueden contar a mano y sumar al recuento de New Words.

En cuanto al colaborador al que queramos solicitar la edición, habrá que consultarle cuánto tiempo estiman para todas las imágenes, salvo en el caso de F (perfil 769 en nuestro sistema de gestión), con quien acordamos un cálculo fijo de 15 min/imagen. Puesto que en Okodia externalizamos todo tipo de tareas de edición de imágenes, tendremos siempre que ser muy claros con qué tipo de edición necesitamos en cada proyecto: si necesitamos editar las imágenes con cuadros de texto, para que queden editables, o si necesitamos editar las imágenes incorporando el texto traducido, y que queden no editables.

Documentos con filenames

NOTA PREVIA IMPORTANTE: Este tipo de archivos puede manipularse de forma que se separe la parte «normal/estándar» del bloque de «filenames». La parte «normal/estándar» podrá traducirse mediante traducción humana o bien mediante MTPE, según las indicaciones del cliente. Además, si se traduce mediante traducción humana y el cliente lo solicita, se le pueden excluir repeticiones/100% FM. En el caso del bloque de filenames, solamente se podrá realizar mediante traducción humana con el recuento especial indicado más adelante.

• Para la traducción

Mucha documentación que traducimos para PSI contiene nombres de archivos (filenames) dentro del texto para traducir.

Por regla general, el nombre exacto de un archivo es algo que no corresponde traducir; esa es la práctica habitual. Sin embargo, PSI nos ha pedido traducirlos, con una estructura específica: manteniendo el filename original e incluyendo la traducción entre corchetes, con una coletilla específica. Ejemplo de traducción PT>EN:

ANEXO_05_Termo_de_consentimento_livre_e_esclarecido_principal_versao_10Dez23_limpo_Dr_Colturato.docx [translated into English: ATTACHMENT_05_Main_Informed_Consent_Form_ version_10Dec23_clean_Dr_Colturato.docx]

La coletilla que precede a la traducción tendrá siempre ese exacto formato: cursiva y primera letra de “translated” en minúscula.

En este caso “translated into English” se ha escrito en inglés, porque el ejemplo es de una traducción PT>EN, pero esto se traducirá siempre al idioma de destino que sea. Por ejemplo, si es una traducción a español, será [traducido a español (LatAm): XXXX]. Si el idioma de destino tiene una variante específica, se incluirá también en la coletilla.

IMPORTANTE: nos corresponderá (y al traductor) diferenciar los filenames propiamente dichos, de las “descripciones” de archivos. Todo se traduce, pero lo primero se hará con el formato bilingüe que acabamos de describir y lo segundo, poniendo directamente la traducción, como cualquier otro contenido del texto.

Estos son algunos ejemplos de filenames (no todos necesariamente acabarán en extensión):

MOR208C310_Hoja de Información principal_v5.0_COL_español_17-NOV-2022

PB_INFORMAÇÕES_BÁSICAS_DO_PROJETO_21 81 1 85.pdf

Protocolo RPC01-3202_ Ozanimod__versión 6.0_ 14 de junio de 2021

Estas son descripciones (no necesariamente la presencia de _ denota que es un filename):

MOR208C310_Carta IP médicos para reclutamiento de pacientes_Version 1.0 dd 19-May-2022 traducción del inglés al español 28-Sep-2022

Protocolo V 7.0 del 28 de octubre de 2022 en inglés y español.

01_Brochura do Investigador versão 10 de 05 de julho de 2022 – limpa-Word e PDF

Los filenames suelen ser más esquemáticos y tener abundantes barras bajas y las descripciones suelen ser más desarrolladas o incluir información de las distintas versiones disponibles. El matiz entre ambos suele ser muy sutil y la apariencia muy similar. Muchas veces lo que nos ayudará a decidir cómo enfocarlo es el contexto textual, la ubicación de esas frases dentro del documento.

• Para el presupuesto

Notas previas:

• en caso de que el cliente solicite que se excluyan repeticiones y 100% matches en archivos que contienen filenames, consultar previamente este enlace.
• en caso de que el cliente solicite hacer MTPE en archivos que contienen filenames, consultar previamente este enlace.

Las palabras unidas con _ no se contabilizan en Trados como deben. Se informó de esto a PSI y acordamos calcular una media de 10 palabras por filename.

El modo de mirar esto es a simple vista contándolos en el documento original o abriendo el documento analizado en Trados (sdlxliff) y haciendo scroll contando más o menos cuántos filenames hay. Contaremos más o menos cuántos filenames hay, no cuántos segmentos (un filename puede estar dividido en distintos segmentos. Si vemos eso, contemos todos ellos como 1).

Luego, multiplicamos cada filename por 10 y añadimos ese recuento al recuento de New Words. Para ayudarnos con ese cálculo podemos utilizar la calculadora de filenames del CRM.

• Para los jobs

Dado que en el report no se contabilizan las palabras unidas con _ como deberían, esto también afecta a los recuentos para los traductores. Además, el report puede contener 100% matches de filenames que realmente no sean 100%. Algún traductor que normalmente no cobra por 100% matches y repetitions, y que conoce las indicaciones del cliente y sabe que debe traducir correctamente esos falsos 100%, puede que nos escriba al finalizar el encargo pidiéndonos modificar la OP añadiendo X palabras por dichos filenames. Lo añadimos en New Words dentro del job (el resto del recuento se queda intacto).

Si preferimos, también podemos añadirle al traductor el recuento de la multiplicación del número de filenames por 10 tal y como hemos hecho con el cliente desde el principio.

• Para nuestro control de calidad

Ver apartado «Control de calidad y entrega > Xbench».

Bibliografía/references/publications

En general, el cliente quiere traducir las bibliografías (aunque hay algunos casos más bien puntuales donde deciden no traducirlas). Por ejemplo, casi siempre se traduce en el caso de protocolos, IB e IMPD. Debido a esa tendencia general y por practicidad, incluiremos las bibliografías en todos los presupuestos para este cliente (pese a que el procedimiento general en traducción es otro), pero siempre lo mencionaremos al enviarle el presupuesto, por si acaso lo quisieran de otra forma.

Si se traduce, será del siguiente modo. Ejemplo de traducción EN>PT-BR:

Bafadhel M, McKenna S, Agbetile J, Fairs A, Desai D, Mistry V, et al. Aspergillus fumigatus during stable state and exacerbations of COPD [Aspergillus fumigatus durante o estado estável e exacerbações da DPOC]. Eur Respir J. 2014;43:64–71

Asegurémonos de enviar a los traductores este ejemplo, como referencia, y la siguiente indicación (escrita aquí en inglés para poder compartirla directamente con los traductores):

The references within the bibliography may contain elements such as cities, countries, dates, phrases such as “Last visit on XXX” or “Pending publication”. If any, these elements need to be directly translated in target language (not keeping source wording).

En trabajos de track changes donde aparezcan referencias bibliográficas entre los cambios marcados del original, comprobaremos cómo salen las referencias en la traducción para saber cómo debemos proceder: si debemos traducirlas o si solamente tendremos que incluir las referencias tal y como salen en el original. Si las referencias presentes en la traducción tienen algún formato específico, asegurémonos de añadir las nuevas referencias del mismo modo.

Proyectos donde piden no contabilizar repeticiones o/y 100% matches

En ocasiones, en algunos proyectos de traducción PSI nos pide excluir las repeticiones o/y los 100% matches del recuento, es decir, no presupuestarlas y, por lo tanto, no trabajar en ellas ni en la fase de traducción ni en la de revisión.

Cada gestora de proyectos tendrá un papel proactivo a la hora de exponer los peligros de este enfoque. Ya se informó a PSI al respecto de manera general, pero de manera específica en el caso por caso, si detectamos que podría llevar a errores en la traducción, será mejor explicárselo al cliente y, en caso de que acepten nuestra sugerencia, no enfocar el proyecto de ese modo. Si insisten, por supuesto, procederemos según deseen, pero de este modo ya serán conscientes de los riesgos asociados y será su responsabilidad.

Ejemplos de proyectos donde defenderemos NO seguir ese enfoque o realizar una gestión específica:

• Rangos de laboratorio: en estas traducciones aparece un gran número de 100% matches. Sin embargo, son textos con muchas palabras sueltas y elementos cortos que en contexto se pueden traducir de distinta forma, por lo que es muy probable que los 100% matches de la TM no sean correctos o requieran revisión; sería peligroso no trabajar en ellos. De igual modo, puede haber palabras repetidas a lo largo del documento que, dependiendo del contexto, se tengan que traducir de una forma u otra.
• Archivos con filenames: Trados no reconoce correctamente las repeticiones ni las coincidencias del 100% en los segmentos con filenames, por lo que dichos segmentos se deben contabilizar de forma estándar. Para ello se debe “romper” el archivo y tratar de forma separada la parte central de la parte de filenames. En la parte principal del documento se podrán excluir repeticiones y 100% matches pero el bloque de filenames se contabilizará en la forma habitual en que se contabilizan los filenames, es decir, tal y como se explica aquí. Para ver el paso a paso de cómo gestionar este tipo de archivos, consultar el curso Paso a paso para excluir repeticiones y 100% matches en archivos con filenames.

En el presupuesto, las líneas correspondientes a los rangos que haya que excluir se modificarán manualmente en Plunet a coste 0. Para analizar los documentos y prepararlos de manera correcta, se ha desarrollado un procedimiento específico que se ha de seguir, detallado en el curso de Okodemy «Gestionar trabajos de PSI sin contar repeticiones/100%«.

Puesto que se trata de un proceso alternativo al habitual, con la finalidad de ahorrar costes, añadiremos al presupuesto tiempo de preparación en una partida de Hour(s) File Preparation, que incluirá:

• tiempo por bloquear/pretraducir segmentos: 0,5 h en todos los proyectos.
• tiempo por revisión de formato de las partes bloqueadas. Multiplicamos el total de palabras bloqueadas por 0,343 segundos/palabra y dividimos entre 3600 para obtener el tiempo en horas. Es decir: Tiempo en horas = (palabras * 0,343) / 3600.

Se ha creado esta calculadora que directamente calcula la suma de ambos conceptos.

• en el caso de que se trate de un trabajo de Documentos con filenames, añadiremos además 7 minutos por documento redondeando en cuartos de hora y con un mínimo de 0,5 h para la separación y preparación diferenciada del bloque «normal/estándar» del bloque de «filenames».

Edición de PDF

Si no se logra descifrar alguna parte del PDF, tenemos libertad para añadir [illegible].

Cuando un documento PDF contenga elementos visuales, como logos, sellos, códigos QR, firmas, etc., quieren reemplazarlos por lo que PSI llama “placeholders”. Es una descripción entre corchetes, de este estilo:

[Logo Plataforma Brasil]

[Signature]

[Coat of arms]

Todos estos elementos deben traducirse, como el resto del contenido del archivo. Quien edite los archivos los describirán en inglés probablemente, pero el traductor tendrá que traducirlos.

Las firmas electrónicas quieren transcribirlas enteras, no poner [Electronic signature] sino [Electronic signature: XXXXX], con el contenido exacto. Lo mismo con cualquier elemento que tenga un contenido traducible. Por ejemplo:

[Stamp: Dr. Colturato

Professional Number 5467]

NOTA: Algunos de estos elementos son nombres de empresas o eslóganes: [Logo: Your future is your choice]

No olvidemos ocultarlo en el Word antes de sacarlo a traducir. No es relevante traducir un eslogan de una empresa.

Los proveedores que nos editan los archivos PDF a menudo recrean los logos con colores y aplicando distintos formatos. El contenido de los placeholders, y la propia palabra “Logo”, “Stamp”, “Signature”, debe tener el formato más neutro posible (lo cambiará la PM al revisar si lo ve editado de otra forma): mismo color de letra que el resto del texto (normalmente negra), sin negrita/cursiva/subrayado, sin colores. Son solo descripciones, no hay que recrear su formato. Si en estos elementos aparecen siglas, hay que escribirlas en mayúscula.

Trabajamos con una variedad de proveedores que desconocen las preferencias de cada cliente, por lo que podemos compartir con ellos estas indicaciones.

EXCEPCIÓN SOBRE AÑADIR PLACEHOLDERS:

No quieren editar/describir/transcribir los logos/sellos en protocolos, IBs, IMPDs y documentos dirigidos a pacientes: ICFs, patient cards, patient diaries, leaflets… documentos que normalmente recibiremos en Word. Ante la duda de si mantener un elemento visual dentro de un documento editable o sustituirlo por un placeholder, consultemos al cliente.

Pie de página (Footer)

Información general

Las siguientes directrices generales aplican a todo tipo de proyecto (traducción, revisión, adaptación, back-translation, etc.), aunque algunos de estos tipos tienen además otras indicaciones específicas que se explican en sus apartados correspondientes.

Estas directrices aplicarán por igual a todos los formatos editables. En Excel o Powerpoint, habrá que consultar al cliente exactamente dónde quieren que lo agreguemos.

Los documentos originales que recibimos pueden tener un pie de página, o no. Independientemente de ello, hay que agregar un pie de página específico (lo que conocemos como PSI-footer) en todos los documentos que entreguemos, lo mencione el cliente en su solicitud o no (es una norma implícita).

EXCEPCIONES: las indicaciones de esta sección no aplican en los siguientes casos en los que no hay que añadir PSI-footer:

• Proyectos a griego
• Proyectos desde/a ES-US
• Clinical Trial Agreements, o contratos de cualquier tipo
• Labels (etiquetas)

Veamos un ejemplo en inglés de la estructura esencial del PSI-footer:

Protocol No. CD101.IV.3.05

Calibration Approval – Centrifuge dated 10 May 2023

Translation from Spanish into English dated 04 January 2024 

Page 1 of 1

Dejaremos siempre una línea en blanco encima del pie de página, para que quede separado del texto principal, y ninguna línea vacía al final bajo la información del número de páginas.

Si el documento para traducir ya tiene un pie de página (o varios distintos en diferentes páginas), se mantiene(n) en el área destinada para el pie de página y, debajo, añadiremos el PSI-footer, que deberá ser igual en todas las páginas del documento. Se procederá del mismo modo cuando el original sea un PDF que editamos en Word.

Este es el procedimiento estándar, pero en ocasiones no será tan sencillo como añadir el PSI-footer debajo del existente: la información del footer no debe ser redundante. Si el pie de página que ya consta en el documento contiene alguna información que normalmente añadiríamos en el PSI-footer, no debemos duplicar la información, sino que debemos fusionar los footers, pero conservando la estructura del PSI-footer. Es decir, pegaremos en nuestro documento un ejemplo del PSI-footer, que modificaremos usando la información relevante que ya consta en el footer existente. Ejemplo:

Vemos también que en el ejemplo anterior no se ha incluido en el PSI-footer la línea relativa a la versión global. Ampliar información en «Consideraciones específicas» de este mismo apartado.

En ocasiones puntuales, el documento original contiene información del tipo de documento no dentro del área de pie de página sino del encabezado. En esos casos, añadiremos/completaremos el PSI-footer en el encabezado, y no en el área del pie de página.

Todos los footers (PSI-footer y footers existentes en el documento) deben traducirse. EXCEPCIONES:

• en traducciones a tailandés nos han pedido que se mantengan en inglés.
• en traducciones a chino tradicional nos han pedido que se mantengan en inglés y que pongamos «Traditional Chinese» (Translation from English into Traditional Chinese dated XX) y no «Chinese (Traditional)» ni referencia a que es para Taiwán.

NOTA: Tanto el ejemplo anterior como otros ejemplos en el manual están en inglés, pero son solo ejemplos. En todo momento todo el contenido de los footers deberemos añadirlo/traducirlo en idioma de destino.

Contenido

El contenido exacto del PSI-footer será diferente en cada documento. Lo redactaremos siguiendo la estructura del ejemplo del apartado anterior y las siguientes indicaciones:

• Línea 1 – código de protocolo.

El código de protocolo está indicado en todos los asuntos de email del cliente.

• Línea 2 – descripción del documento.

En la línea de descripción del documento el cliente busca que, en esencia, describamos qué tipo de documento es. En la práctica, para redactar los footers, partimos del propio nombre del archivo, porque PSI nombra cada documento con una descripción bastante exacta de qué tipo de documento es y eso nos facilita las cosas. Sin embargo, los filenames de los archivos son muy esquemáticos, todas las palabras van unidas por barra baja en lugar de espacios. PSI busca una línea de “file description” natural, más desarrollada, separando las palabras con espacios y los distintos elementos, disponiendo la información de manera fluida. Si aparecen abreviaturas y conocemos su significado (el contenido del documento puede darnos pistas), prefieren que desarrollemos las palabras en el footer. Además, los filenames incluyen información que no siempre es relevante a la hora de describir qué tipo de documento es. Debemos excluir del footer información sobre los sites (centros de estudio) o los nombres de investigadores, que aparece en algunos documentos al comienzo del filename, detrás del código de protocolo. Estos elementos se reconocen solo con la práctica:

Solo hay que describir el tipo de documento, incluir el número de versión y la fecha. Si alguna de estas informaciones no aparece en el filename, la buscaremos dentro del documento y, si no consta (ej. documentos sin fecha), no se incluirá en el footer.

EXCEPCIÓN: en proyectos desde y a thai, sí quieren que incluyamos en el footer todas las informaciones que aparezcan en el filename del documento.

• Línea 3 – información sobre la traducción.

En la línea de información sobre la traducción se incluirá el estatus de la traducción solamente en el caso de documentos destinados para pacientes.

Sobre la fecha de traducción, tengamos algo en cuenta: como añadiremos el footer antes de comenzar a traducir, podemos dejar la fecha sin anotar (pero debemos acordarnos de hacerlo al revisar las traducciones), o bien escribir la fecha de entrega límite acordada con PSI. Si se acaba entregando en una fecha diferente (ej. adelantamos la fecha de entrega), tendremos que modificar la fecha de la traducción antes de entregar. Para la combinación de idiomas, recordemos que nunca se incluye la variante del idioma de origen, salvo en footers de back-translations. Sí se incluye siempre la variante de destino (excepto para inglés, español de España y portugués de Portugal).

• Línea 4 – número de página

La línea de información de número de página es parte esencial del PSI-footer. Si el footer existente en el documento original ya incluye el número de página, se borrará de ahí por ser redundante y solo indicaremos la información de página como parte del PSI-footer. En ocasiones, en el header/footer del original aparece una paginación interna del documento, que no coincide con el número de hojas reales del archivo. Si la paginación interna no coincide, no es redundante, así que hay que mantenerla en las traducciones.

Estas son las líneas en torno a las que se construye el PSI-footer más básico. Ver el apartado «Consideraciones específicas» para excepciones según tipos de documentos y otros motivos.

Formato

El formato exacto es importante para el cliente, así como para mantener la máxima consistencia en todas nuestras entregas. Lo quieren en tamaño 9, interlineado sencillo y alineado a la izquierda, salvo la información del número de página centrada. Como tipografía, usaremos el mismo tipo de letra que predomine en el documento.

Encontraremos aquí distintos ejemplos de footers en diferentes idiomas de destino. Para conservar el formato exacto en los footers en nuestras entregas, es recomendable copiar el footer directamente de dicho Word y pegarlo en nuestros documentos para traducir (tras copiarlo, modificaremos el contenido de nuestro footer como sea necesario).

Proceso

Agregaremos el PSI-footer a cada documento antes de sacarlo a traducir por varios motivos:

• Copiaremos uno de estos ejemplos de footer que ya esté en el idioma de destino que necesitamos. Si conocemos el idioma de destino, modificaremos el contenido como corresponda y, si lo tenemos ya entero traducido, lo ocultaremos entero. Sin embargo, otras veces necesitaremos que el traductor traduzca la línea 2 (o cualquier otra), así que esas partes habrá que dejarlas sin ocultar. Por eso, el footer debe estar ya en los documentos a la hora de analizarlos, para que pase al SDLXLIFF con el que trabajará el traductor.
• Habitualmente el proceso de añadir footers lleva un buen rato. Hagámoslo mejor al comienzo que el día de la entrega, que no sabemos de cuánto tiempo dispondremos o lo que pudiera surgir.
• Por consideración hacia nuestras compañeras en caso de que, por el motivo que sea (planeado o inesperado), tengamos que dejar pendiente ese encargo y lo retome otra persona.

Consideraciones específicas

A continuación se explican algunos casos donde, además de las normas anteriormente descritas, aplicarán otras adicionales.

Documentos dirigidos a pacientes

Los documentos dirigidos a pacientes (que PSI denomina patient-oriented documents) son todos aquellos que se redactan para el uso directo de los pacientes de un estudio. Los más conocidos son los Informed Consent Forms (ICFs) pero esta categoría abarca un gran número de materiales como los patient dosing diaries, leaflets, patient cards… Normalmente, por su contenido identificaremos si un documento se destinará al paciente o al personal médico del estudio.

Los documentos dirigidos a pacientes se rigen por las siguientes normas particulares (atención: estas directrices no aplican en el caso de documentos para EE. UU. Ver apartado Documentos para EE. UU.).

Status

Se debe añadir status de la traducción en la línea 3 del footer en todos los documentos dirigidos a pacientes. En cualquier otro tipo de documento pondremos solamente “Translation…”, mientras que en estos documentos pondremos:

• “Draft translation” → sea una traducción desde cero, o sea un trabajo de control de cambios (en el momento en que añadimos cambios en una traducción, PSI deberá revisarlo, así que se considera borrador).
• “Final translation” → cuando ya han revisado el trabajo y nos piden «finalizar» el documento, cambiamos “Draft” por “Final” (o lo enviarán ellos ya cambiado).

Aquí se mencionan las palabras en inglés pero en cada documento se incluirán traducidas al idioma de destino correspondiente.

Global/Master version

En ocasiones, el footer preexistente en algunos documentos originales (normalmente ocurrirá en documentos dirigidos a pacientes) contiene información sobre la versión global/maestra. Si existe referencia a la versión global/maestra y también información country-specific, en esos casos no hay que traducir/incluir en el footer la información global/maestra. La eliminamos cuando dejemos añadido el PSI-footer; solo dejaremos información country-specific.

En el 99% de los casos aparecen ambas informaciones (la global/maestra y la country-specific), por lo que aplica la norma anterior, pero si excepcionalmente solo hay referencia a la versión global/maestra, si se incluirá/traducirá.

Patient cards

Son materiales de paciente que suelen tener un formato rectangular, con el texto ubicado dentro de un marco. Se le entregan al paciente impresos como una tarjeta, por lo que mantener el formato es especialmente importante.

En estos documentos, PSI quiere el footer tanto en el área de footer habitual como dentro del marco de la tarjeta.

• Dentro de la tarjeta: Si la tarjeta está a doble cara, lo añadiremos solamente en el reverso (normalmente, la segunda cara). Únicamente añadiremos la línea con la descripción del tipo de documento, versión y fecha (a menudo ya consta en el original, se traduce eso. Si no, lo añadimos) y la línea con información sobre la traducción, estatus, idiomas y fecha.
• En el área de footer: añadiremos el PSI-footer completo, en todas las páginas.

Not study-specific documents

Formalmente sí son proyectos que pertenecen a un estudio específico a efectos de presupuesto/facturación, solo que hay documentos cuyo contenido en sí no está estrechamente relacionado con ningún estudio en particular. Son lo que PSI llama “not study-specific”. A veces lo indican en su solicitud, pero otras veces no, así que hay que aprender a identificar cuáles son estos documentos.

Para estos documentos no hay que mencionar el código de protocolo en el footer (no se incluye la línea 1). La omisión del código del protocolo aplica solo al footer. Sí se mantiene en el nombre del documento en sí, en el certificado de traducción, en Plunet, etc.

Además, como son tipos de documentos bastante genéricos, en la línea 2 del footer con la descripción del tipo de documento añadiremos determinada información adicional que complemente la identificación de ese documento en particular. Algunos de los documentos más frecuentes son:

• Medical licenses
• Credentials
• Laboratory ranges

Aquí encontraremos un listado más exhaustivo de tipos de documentos not-study-specific y qué información adicional quieren ver incluida en la línea 2 del footer justo a continuación de la descripción más esencial sobre qué documento es. Si esta información no sale en el filename del archivo, la buscaremos dentro del propio documento.

NOTA: Medical licences: en ocasiones, los filenames de estos documentos mencionan PL o “Professional License” de manera genérica. Al cliente esto no le sirve como identificativo del tipo de documento, sino que en la línea 2 del footer tenemos que especificar si se trata de una medical license, pharmacist license o nursing license (podrían aparecer los acrónimos ML, PL o NL en el filename. Para el footer hay que desarrollarlos), además de añadir el nombre completo de la persona que ostenta el título (y la versión y fecha, si consta).

Contratos

Si hay un footer preexistente en el documento para traducir, este sí se traduce, pero no aplica el PSI-footer. No se añade.

En el caso de contratos que quieren en formato bilingüe, a doble columna, tampoco se añade PSI-footer y dejaremos sin traducir los elementos externos al propio cuerpo del documento (el footer y el header).

Certificados de traducción (CoT)

[NOTA PREVIA IMPORTANTE: Actualmente, los certificados de PSI se crean diciendo que la traducción se ha realizado con la normativa ISO correspondiente. En caso de que algún trabajo se realice dividiendo la forma de traducción (una parte humana y otra parte posedición, como por ejemplo los archivos con filenames), deberemos crear certificados diferentes. Como por ahora no sabemos cómo actuará PSI en este sentido, cuando ocurra algo así comentémoslo antes.]

Solo se lo enviaremos cuando lo pidan, a excepción de los estudios 270-301 / 270-303 y APVO101-903, que para las combinaciones EN<>PT-BR, siempre quieren CoT.

NOTA: Actualmente, los certificados para todos nuestros clientes se preparan con la herramienta del CRM (en el menú Recursos > Certificados de traducción), que se ha configurado con los distintos requisitos de cada cliente para elaborar cada tipo de certificado de manera semiautomática, por lo que no tendremos que preocuparnos de realizar cambios manuales según el tipo de certificado. Aún así analizaremos a continuación las características de cada tipo de certificado para PSI. 

• Un certificado por documento.
• Campo de Document Description: filename del documento original.
• Campo Translation date: la que aparezca en el PSI-footer del documento en la línea acerca de la traducción. En documentos para EE. UU. (que no llevan PSI-footer), la fecha de entrega inicial de la traducción.
• Campo Document date: fecha del documento que se traduce, que encontraremos en el filename del archivo o en el contenido del mismo.
• Filename del propio certificado, del archivo PDF que enviamos: filename del documento target seguido de _CoT, es decir, acabado en código de idioma de destino_CoT (o CoR en caso de certificados de revisión).

Cada tipo de proyecto requiere una certificación diferente, por lo que en la herramienta del CRM se han creado “distintos clientes”, porque se crearán los CoT en base a distintas plantillas.

La herramienta del CRM tiene diferentes campos para rellenar, para adaptarse a las necesidades de todos los clientes médicos, pero para PSI solamente hay que rellenar los siguientes:

Los campos señalados en verde están disponibles en todos los tipos de proyecto (todo tipo de “cliente” PSI, es decir, sea traducción, revisión o adaptación). Se elige el cliente en función de la categoría del proyecto y los campos en verde se marcan solamente en dos tipos de solicitudes: trabajos de track changes o back-translations.

Sin embargo, para PSI, no en todos los proyectos de track changes incluiremos la mención de haber trabajado únicamente en los cambios marcados. En algunas ocasiones emitiremos un certificado normal (lo que ellos llaman full CoT).

Bajo los campos mostrados en la imagen anterior aparecerá (según el tipo de certificado puede no aparecer, está ya integrado en la plantilla) la certificación específica que va asociada a ese tipo de trabajo.

• Traducciones (estándar):

Para trabajos habituales de traducción escogeremos el cliente “PSI traducción” y la certificación es la que sigue:

I declare that the forward translated document is an accurate translation of the originating document to the best of our knowledge and best processes. The text has been reviewed and edited in accordance with applicable quality control standards (ISO17100:2015).

Para otros tipos de trabajos, aplican otros tipos de CoT y el texto de la certificación varía ligeramente.

• Back-translations:

I declare that the back-translated document is an accurate rendering of the originating [BT’s source language] document to the best of our knowledge and best processes. The text has been reviewed and edited in accordance with applicable quality control standards (ISO17100:2015).

BT’s source language = el idioma original de la back-translation, es decir, el idioma en que está la forward translation

En el campo de Idioma origen, especificaremos la variante exacta, como excepción respecto a la norma habitual de no especificar variante source.

• Certificate of Review (CoR) – revisión:

Todos los derivados de “translation” se cambian por “review”.

I declare that the revised document is an accurate translation of the originating document to the best of our knowledge and best processes. The text has been reviewed in accordance with applicable quality control standards (ISO17100:2015).

• Adaptaciones:

Las adaptaciones quieren reflejarlas en el certificado no como una adaptación de una variante a otra sino como una traducción desde inglés (siempre) a la variante de destino, pasando por la variante original.

Source text will be deemed to be English, unless otherwise specified. The mention via linguistic adaptation from [language variant] will be added in the “Translation Requested” field (e.g. From English to Portuguese (Brazil) (via linguistic adaptation from Portuguese (Portugal)).

Consideraremos el inglés el idioma de origen, porque es en el idioma en que están normalmente los documentos originales de los que procede el texto que adaptamos. El idioma de origen de la propia solicitud de adaptación es el que se mencionará en la aclaración “via linguistic adaptation from…”.

NOTA: en todo caso, la herramienta del CRM está configurada para automáticamente considerar el inglés como lengua de origen. En los campos Idioma origen e Idioma destino anotaremos los idiomas de origen y de destino de la propia solicitud de adaptación, es decir, las dos variantes (se anotará la variante source también en este caso, de manera excepcional). “Inglés” saldrá en el certificado por defecto.

• Track-changes:

En trabajos de track-changes, al marcar la casilla de TC, aparece en el certificado una mención que indica que solo se ha trabajado en los cambios marcados y también modifica ligeramente el tipo de certificación que aplique según el tipo de trabajo (traducción o revisión), ya que en lugar de “document” se habla de “text”:

• • Certificate of Translation (CoT) – traducción de TC:

Only tracked changes of the document were translated and incorporated into an existing [language] document.

+

I declare that the forward translated text is an accurate translation of the originating text to the best of our knowledge and best processes. The text has been reviewed and edited in accordance with applicable quality control standards (ISO17100:2015).

• • Certificate of Review (CoR) – revisión de TC:

Only tracked changes were revised in the existing [language] document.

+

I declare that the revised text is an accurate translation of the originating text to the best of our knowledge and best processes. The text has been reviewed in accordance with applicable quality control standards (ISO17100:2015).

Control de calidad y entrega

Las pautas específicas para determinados tipos de proyecto se mencionan en sus correspondientes apartados. A continuación veremos las directrices generales.

Guía de estilo

La guía de estilo que se encuentra indicada en el campo correspondiente del clienet en Plunet contiene indicaciones que debemos controlar durante nuestro control de calidad.

Xbench

Realizaremos nuestro control de calidad analizando los SDLXLIFFs de las traducciones en Xbench agregando las siguientes herramientas:

• la base terminológica (TB) del cliente
• la memoria de traducción (TM) del cliente
• (opcional, para archivos que contienen filenames) la checklist para filenames

Para aquellos textos que traducimos que contienen filenames o nombres de archivo, se ha creado una checklist específica que, importada en Xbench, nos ayudará en nuestro QA a detectar posibles errores relacionados con la manera en que PSI nos ha pedido traducirlos:

PSI-CRO_checklist.xbckl

La descargaremos desde el servidor Nextcloud PM > TMs > Terminology > Medical > Multiterm > PSI-CRO > xbench.

Comprende varias reglas configuradas para detectar la mayoría de los errores potenciales y se pueden crear más si detectamos carencias en el futuro. En la Guía Rápida de Xbench encontraremos información sobre cómo cargar esta checklist.

Una vez cargada, podemos pasarla a los archivos SDLXLIFF de un proyecto en el menú QA > Run Personal Checklists. Es muy cómodo, puesto que ya se queda cargada en Xbench a menos que la eliminemos (del mismo modo en que se añadió, pulsando en Remove). Si seleccionamos Run Personal Checklists y en ese momento tenemos más de una checklist cargada, Xbench nos consultará cuál de ellas queremos usar.

Para la revisión de textos que contienen filenames se ha creado también Okobench, una herramienta que encontraremos en el CRM > Recursos > Okobench y que nos ayudará en la detección de potenciales errores numéricos y alfanuméricos relacionados con la traducción de filenames.

Formato y lectura diagonal

Tras la revisión en Xbench o/y en Trados, se revisará el formato de los documentos de destino y se hará una lectura diagonal conforme a nuestros procedimientos generales.

• Para realizar nuestro control de calidad, siempre que tengamos el original en formato PDF, revisaremos la traducción contra el PDF, no el Word editado, dado que este último podría tener algún posible error de edición no detectado.
• Si en el documento original aparecen siglas dispuestas en orden alfabético, en las traducciones a PT-BR no las ordenaremos. Salvo esa excepción, podemos seguir estas indicaciones generales cuando aparezcan abreviaturas y siglas.
• Este cliente es muy exigente con el formato de las traducciones. Buscan que la traducción tenga una distribución equivalente a la del original, no necesariamente calcando el original. Por ejemplo, si en el original encontramos cinco líneas en blanco entre un apartado y el siguiente y entendemos que se ha realizado para forzar que pase a la siguiente página, no se mantendrán esos espacios en la traducción si no se necesita hacer eso mismo, y viceversa, en la traducción se realizarán los ajustes que la PM vea convenientes para mejorar la distribución, por ejemplo, pequeños retoques en márgenes de columnas o en el tamaño de la letra para que el texto encaje correctamente dentro de una tabla o un cuadro de texto. No hablamos de modificar al gusto otros elementos de formato más visibles como negritas, subrayados, etc.
• También realizaremos búsquedas de dobles espacios y los corregiremos por un único espacio.
• Recordemos, además, cualquier requisito específico del tipo de encargo, como podría ser la revisión de formato del documento entero, en encargos de track changes.

Nombres de los documentos de destino

Encargos de traducción, revisión o adaptación

El archivo para entregar se ha de llamar como el documento original, añadiendo el código de idioma de destino al final (o, si ya consta el código de idioma original, sustituirlo por el del idioma de destino).

• Ejemplo traducción ES>EN:

PSI envía:

3292OKD_LYT-100-2022-204_Cover letter_Mx_ 24AUG2022_ES

Okodia entrega:

3292OKD_LYT-100-2022-204_Cover letter_Mx_ 24AUG2022_EN

• Ejemplo traducción de documento bilingüe:

PSI envía:

3271OKD_VTX958-202_Data Protection Notice_ES

Okodia entrega:

3271OKD_VTX958-202_Data Protection Notice_ES-EN

• Ejemplo revisión bilingüe:

PSI envía:

(original) 2568OKD_BBT-356_Insurance policy_25SEP2001_EN

(traducción para revisar) ART-258_policy Endurance_10OCT2024_ES

Okodia entrega:

2568OKD_BBT-356_Insurance policy_25SEP2001_ES

Documentos actualizados con cambios marcados

Igual que se actualiza el documento, se actualiza el nombre del archivo, basándose en el nombre de archivo original. Es decir, se le pone el mismo nombre del original pero acabado en código de idioma de destino. Detrás, se añade “_redline”

(excepción: documentos para EE. UU.).

• Ejemplo documento bilingüe:

PSI envía:

3271OKD_VTX958-202_Data Protection Notice_ES-EN_redline

Okodia entrega:

3271OKD_VTX958-202_Data Protection Notice_ES-EN_redline

• Ejemplo documento monolingüe:

PSI envía:

3065OKD_AFM24-102_Master Main ICF_v.2.0_dd.12Apr2022_ES_redline.docx

For 3065OKD_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_EN.docx

Okodia entrega:

3065OKD_AFM24-102_Master Main ICF_v.2.0_dd.12Apr2022_EN_redline.docx

• Ejemplo documento monolingüe para back translation:

PSI envía:

3065OKD_AFM24-102_Master Main ICF_v.2.0_dd.12Apr2022_ES_redline_back-translation.docx

For 3065OKD_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.docx

Okodia entrega:

3065OKD_AFM24-102_Master Main ICF_v.2.0_dd.12Apr2022_ES_redline_back-translation.docx

(si además de las versiones con TC, nos piden que enviemos sus versiones clean, se nombran igual pero sustituyendo “redline” por “clean”)

Back-translations

No se añade código de idioma de destino al final, ya que siempre será inglés. No quieren eso sino saber DE QUÉ idioma es back-translation, es decir, se añade código de idioma source del proyecto de back-translation (el idioma en que está la FT). Detrás del código de idioma, se añade “_back-translation” o, si fuera un proyecto de track changes, “_redline_back-translation” (excepción: en documentos para EE. UU. se hace la mención de “back-translation”, pero no la de “redline”).

Comprobaciones finales

• Confirmar que los comentarios que puedan haber añadido los lingüistas quedaron anónimos. Además, habremos borrado los que no consideremos relevantes y los que decidamos conservar deben quedar redactados de manera genérica, en plural y con lenguaje comprensible para el cliente.
• Revisar que en los archivos finales no quede ningún texto que hayamos podido ocultar en nuestro proceso de trabajo.
• Hacer una revisión final de los pies de página, en todas las páginas del documento (según la configuración del archivo, podrían cambiar entre diferentes secciones): que el PSI-footer quede igual en todas las páginas, que esté traducido, que no tenga texto oculto, que tenga la fecha del día de la entrega y que cumpla con las indicaciones específicas para ese tipo de documento o de proyecto.
• Revisar que los documentos de destino estén nombrados como corresponden, recordando renombrar los actualizados en proyectos de track changes.
• Revisar el hilo del cliente para consultar cualquier detalle, como si necesitaban CoT o no. Para la preparación de CoTs revisar las indicaciones generales y las específicas que puedan constar en los apartados de los distintos tipos de proyectos.
• Realizar la entrega en el hilo de email de la solicitud.

Fase posterior a la entrega

Una vez finaliza un proyecto, el cliente podría volver a escribirnos en el hilo del proyecto para enviarnos las traducciones con alguna sugerencia tras la revisión por parte del equipo de proyecto o para pedirnos un certificado.

Tendremos que encontrarlo en Plunet para ver qué tipo de proyecto fue, qué tipo de certificado emitir, así como para guardar los archivos finales/certificado. Aquí tenemos algunos consejos para realizar búsquedas de proyectos en Plunet de manera eficaz.

Revisión de sugerencias del cliente

En Okodemy tenemos un ejemplo práctico que muestra cómo gestionar este proceso: “Ejemplo – Resolución tras el envío de dudas por parte de un cliente después de la realización de una traducción con su posterior back-translation”.

PSI llama reconciliation of changes al proceso por el que nos devuelven una traducción tras su revisión interna por parte de PSI. No los revisa directamente el interlocutor pertinente de PSI, sino un equipo de proyecto (project team) determinado, externo a PSI. Cada encargo lo revisa una persona o equipo de personas distinto. Para evitar confundir este proceso con la reconciliation como paso posterior a una back-translation o con un trabajo cambios marcados, llamaremos a este proceso revisión de las sugerencias del cliente.

Aunque no es tan frecuente que nuestros clientes nos devuelvan las traducciones con comentarios o sugerencias de cambios, es algo estándar en nuestra relación con PSI, ya que este proceso forma parte de su fase de finalización para determinados tipos de documentos.

Recepción, plazo y coste

El cliente nos escribe por el hilo de un encargo ya finalizado, nos envía las traducciones “for file finalization”, o “for CoT issuance” o “for reconciliation of changes” o nos piden revisar/consultar con nuestros lingüistas los cambios realizados en las traducciones. No suelen mencionar el plazo en que lo necesitan. Como norma no escrita, solemos ocuparnos de ello para ese mismo día laborable o el día siguiente. Dependerá de la combinación de idiomas, el número de cambios, la disponibilidad del traductor o la urgencia por parte de PSI. Ante un alto volumen de cambios o casos en los que proceda presupuestar este proceso, la PM podrá negociar determinado plazo con el cliente.

Todo lo relativo a cómo contabilizarlo para el presupuesto y al proceso en sí se explica en el apartado Seguimiento del manual de procedimientos generales de PM. A continuación algunos apuntes adicionales que nos ayudarán en este proceso con PSI:

• Siempre el primer paso será abrir los documentos y valorar lo que encontramos, para decidir tanto si precisa costes adicionales o no, como el proceso que deberemos seguir.
• Si recibimos comentarios o/y cambios out-of-scope, confirmemos con el cliente si quieren que los miremos o no. A menudo PSI actúa como intermediario entre el project team y nosotros, sin consultar lo que nos envían. Si en las sugerencias/correcciones hay errores, lo más probable es que quieran corregirlos, pero si son preferenciales, en ocasiones nos han dicho que prefieren no tocar nada, porque esas versiones previas ya quedaron aprobadas de ese modo. Por eso, le indicaremos al cliente si se mencionan errores o son cuestiones preferenciales para ayudarles a decidir si miramos todas las sugerencias out-of-scope o solamente lo que aparezca en las partes en las que trabajamos en ese proyecto.
• Debemos tener claro qué necesitan de nosotros en cada caso. Algunos revisores del cliente mencionan que hay un error, pero lo mencionan en un comentario, no hacen la corrección por todo el documento. Hay otros que no añaden comentarios sino que hacen todos los cambios que consideran por todo el documento. Hay revisores que hacen una mezcla de estos enfoques.

Cuando encontremos que todo son cambios, tendremos que revisarlos todos uno a uno. Si se han modificado términos clave, hay que revisar que quedaron modificados en todo el documento, que no se hayan olvidado ningún caso.

Cuando haya comentarios con sugerencias pero no hayan hecho los cambios correspondientes por todo el documento (o hicieron cambios pero de manera aislada o solo la primera vez que aparece ese término), les consultaremos qué quieren que hagamos. Puede haber dos enfoques que implicarán una dedicación muy distinta:

• • Revisemos los comentarios/los pocos cambios que haya, confirmar si nos parecen correctos o no y decírselo, y el project team se ocupará de realizar todos los cambios pertinentes en todo el documento.
  • Revisar sus sugerencias y, si las consideramos correctas, encargarnos de realizar todos los cambios pertinentes en el documento/completar los cambios que no hayan realizado de manera consistente por todo el documento.

En conclusión, abriremos siempre los documentos, veremos qué clase de correcciones se han hecho, si hay sugerencias que no han quedado implementadas en el documento, confirmaremos con ellos qué enfoque quieren que adoptemos durante nuestra revisión (les podemos explicar las dos opciones) y, entonces, si no se trata de errores y si consideramos que la tarea de revisión superará la media hora, prepararemos un presupuesto (Hour(s) Review) y esperaremos su confirmación para ponerlo en marcha.

Cuando no implique presupuesto, confirmaremos al cliente recepción de los documentos y les diremos que procedemos a consultarlo con nuestro equipo de lingüistas y les diremos algo lo antes posible.

Proceso de revisión

A veces los cambios son mínimos o tan sencillos que, dependiendo del idioma involucrado, la PM podrá confirmar o corregir esos cambios/sugerencias ella misma. Cuando no sea el caso, contactaremos con la persona encargada de la fase de revisión (si no está disponible o hay otro motivo relevante, con la de traducción). Por supuesto, si surge algún debate complejo o un término en particular para el que conviene asegurarnos, podremos contactar con las dos personas involucradas en el encargo, pero de manera habitual solamente contactaremos con una.

Si al cliente se le envió un presupuesto, da lugar a una nueva Order.

Si no implica presupuesto, escribimos al revisor en el hilo de email de entrega o de asignación de ese proyecto y se le pide si puede mirar los comentarios/cambios para la fecha/hora que necesitemos.

Compartamos las siguientes indicaciones con el revisor:

• Le indicaremos que revise tanto comentarios como cambios marcados (si se trata de un proyecto de track changes, le podemos ayudar indicándole el nombre de usuario del revisor, para que pueda visualizar solo esos cambios marcados). Le pediremos que mire todos los comentarios y que realice los cambios que haya que hacer en todo el documento (salvo en los casos en que las sugerencias del cliente no le parecen correctas).
• Si las sugerencias/cambios son preferenciales y no son incorrectas, es decir, si el revisor aceptaría usar esos términos en el futuro, lo daremos por válido.
• Si cualquier sugerencia no es la más adecuada y tiene reticencias, no lo daremos por válido y necesitamos que justifique por qué, añadiendo un comentario o contestando a los comentarios existentes. (No es necesario responder a los comentarios con los que sí está de acuerdo). PSI confía en nuestro criterio a menudo por encima del de sus revisores, así que expongamos siempre lo que sea más adecuado desde el punto de vista lingüístico para que puedan valorarlo.
• Si ve errores de ortografía en las correcciones del cliente, debe corregirlos.
• No se deben aceptar/rechazar las correcciones marcadas con track changes realizadas por el cliente. Si está de acuerdo, se dejan tal cual y si no, se añade un comentario.
• El revisor debe hacer todas las correcciones con control de cambios activado.

Verificación, terminología y entrega

Miraremos siempre lo entregado por el revisor. A menudo hay que retocar el contenido de algún comentario o corregir algún error de ortografía que se haya colado en cualquier cambio en el texto.

En lo relativo a la terminología, consultar el procedimiento general para ver qué pasos hay que seguir.

Respecto a la posible incorporación de términos a la base terminológica, la PM valorará si alguna sugerencia del cliente corresponde a terminología clave, es decir, evitaremos cambios en verbos, expresiones… hablamos de términos técnicos.

• Extraerá esos términos source y su traducción target y confirmará con nuestro revisor si estaría de acuerdo en utilizar esos términos en futuras traducciones, para añadirlos en la base terminológica.
• Solo si el revisor da su visto bueno (si no le convence algún término, no se consultará al cliente sobre él ni se añadirá a la base terminológica. Se tomará como puntual para ese proyecto), entonces compartiremos con el cliente el listado de términos que hemos extraído y les consultaremos si esas preferencias se consideran específicas para ese texto o si querrían que traduzcamos esos términos de ese modo en todas (recalcar) nuestras traducciones. En ocasiones entienden que muchas sugerencias son preferenciales de sus revisores y no pretenden que las usemos en nuestras traducciones.
• Si el cliente confirma que prefiere que se usen en el futuro, pediremos por email a JMM que añada esos términos a la base terminológica del cliente. A la hora de elaborar el Excel para JMM, es importante seguir estas directrices comunes para una mayor calidad de nuestras bases terminológicas.

Si en su email PSI pidió que, junto con la revisión, preparemos el certificado de traducción, la fecha para el CoT la indicará el cliente en su email o, si no, será la que aparezca en el pie de página de la traducción que nos han enviado para finalizar.

PSI quiere que entreguemos el archivo revisado tal y como ellos lo enviasen nombrado pero añadiendo “_Reconciled” al final. El documento revisado y/o CoT los guardaremos conforme explica el procedimiento general. Tras guardar los archivos, entregamos los documentos a PSI y, si algún comentario queda pendiente de resolver por su parte para poder finalizar la revisión, la PM quedará pendiente de consultarles en unos días.

Preparación de certificados de traducción posterior a la entrega

Existen dos posibles casos principalmente:

• A menudo el cliente no pide certificado de traducción (CoT) cuando solicita la traducción sino una vez ha transcurrido un tiempo desde la entrega (no nos reenvían la traducción; solo piden el CoT). Con los detalles del hilo, donde probablemente veremos adjunto el presupuesto que nos ayudará para localizar el pedido, o bien con el nombre del archivo/el asunto del email, ubicaremos en Plunet el proyecto y el tipo de trabajo que se realizó para emitir el tipo de certificado que corresponda. La fecha del CoT será la que aparezca en el footer de la traducción que enviamos (a menos que pidan otra), así que tendremos que buscarla. Si no hay footer en la traducción, pondremos la fecha de entrega. Guardaremos el CoT en la carpeta Final del pedido correspondiente.
• Otras veces nos piden el CoT enviándonos la traducción finalizada, diciendo que tras su revisión interna dan nuestra traducción por válida sin hacer cambios. Aunque digan que no han hecho cambios, conviene abrir el archivo que adjuntan y confirmar lo siguiente antes de proceder:
  • No compararemos los documentos que recibimos con los que nosotros entregamos, porque llevaría mucho tiempo, pero sí conviene refrescar las características de ese encargo y comprobar si en nuestra entrega/en los documentos les hicimos algún comentario sobre algún término o alguna cuestión que PSI tuviera que confirmar.

Si están finalizando el documento sin confirmar o pasando por alto alguna cuestión relevante que surgió durante el desarrollo del proyecto, insistamos en esas cuestiones antes de preparar el CoT, indicándoles que los documentos no deberían finalizarse tal y como los han enviado.

• • Si el documento no tiene ninguna cuestión pendiente y está todo en orden, les enviamos el CoT. En estos casos en los que no han realizado cambios en la traducción, guardamos igualmente las versiones que nos envíen y el CoT en la carpeta dentro de Final. (Aunque la propia traducción sea la misma, normalmente sí cambian algunas pequeñas cosas: la fecha del pie de página; el status de la traducción, según el caso; TC aceptados, etc.)

La fecha del CoT será la que aparezca en el footer de la traducción finalizada (a menos que pidan otra). Si no hay footer en la traducción, pondremos la fecha de entrega.

Anexo 1 – Procedimiento específico para determinados tipos de proyectos

Trabajos de Track Changes

Estos trabajos pueden ser de traducción, de revisión, de adaptación… y lo que implican es que solamente trabajaremos en las partes que aparezcan en el documento original con cambios marcados (lo que denominamos habitualmente track changes, TC).

Los requisitos del cliente y los procesos que tendremos que seguir dependerán del tipo de proyecto.

Los trabajos de track changes se realizan cuando un documento se ha actualizado fruto de una enmienda en el estudio y hay que actualizar su traducción previa. Es el proceso por el que un mismo documento se actualiza de una versión a otra posterior. De manera esporádica, podríamos tener proyectos que no sean enmiendas convencionales, lo que conocemos como «track changes no estándar».

Indicaciones básicas

A continuación, algunas indicaciones clave que tendremos en cuenta y que compartiremos con todos los lingüistas involucrados en los proyectos de track changes:

• Formato de los cambios marcados → nos han pedido que siempre implementemos los TC siguiendo el mismo formato, la misma disposición que tienen en el original. No se refiere a conservar el mismo orden (que si en el original aparece primero la frase tachada y detrás la nueva frase añadida, tengamos que hacerlo en el mismo orden en la traducción); tenemos más libertad en ese sentido. Se refieren, por ejemplo, a que si se han realizado varios cambios dentro de una tabla, debemos realizar dichos cambios, uno a uno, en la tabla traducida. En cambio, si en el original aparece la tabla previa tachada entera y una nueva tabla añadida, procederemos igual en la traducción.

Habrá casos en que se complique cumplir con este requisito, porque en muchas ocasiones los documentos originales que recibimos son comparaciones automáticas de Word, que muestran los TC de un modo que será muy difícil replicar manualmente, por ejemplo, tablas con profundos cambios de estructura.

O varios párrafos seguidos tachados al completo, salvo por unas pocas palabras sueltas entremedias, que acaban conformando todas juntas una única frase (en lugar de tachar el apartado entero y añadir la frase correspondiente).

No podemos decidir por nuestra cuenta actuar como nos resulte más conveniente (en particular en lo relativo a tablas), así que cuando nos encontremos con puntos conflictivos, debemos comentarlo con el cliente y pedir su autorización para tachar entero todo el texto en cuestión y añadir el nuevo.

• Autor anónimo → conforme a nuestro procedimiento general, tanto los cambios como los comentarios que se realicen en el documento han de ser anónimos e, idealmente, cada lingüista debe usar el seudónimo que coincida con el papel que realice en el proyecto: el traductor usará “translator”, el revisor “reviewer” y también puede haber un tercer nombre de usuario que corresponda con de la gestora de proyectos.

Trabajamos con gran variedad de lingüistas con diferente experiencia en trabajos de cambios marcados, así que recordemos indicarles que deben cambiar el nombre de usuario en Word por “translator” o “reviewer”, el que proceda, y derivarles a la información de cómo hacerlo: en el email de asignación de todos los trabajos de TC aparecerá en Work Instructions un enlace a un artículo de la Translators Knowledge Base que contiene todas las instrucciones relevantes para trabajos de cambios marcados.

Presupuesto

Salvo que el cliente dé otras indicaciones, para el presupuesto en Plunet (así como para el certificado) utilizaremos el nombre del documento original con track changes. EXCEPCIÓN: documentos para EE.UU., que utilizaremos el nombre del original con los cambios aceptados (clean).

Normalmente, PSI enviará dos archivos por cada documento para actualizar. Por ejemplo:

103OKD_ABC-222_Main ICF, version 2.0 dd. 14-June-2022_EN_redline

For 103OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US

(si, además encargasen una back-translation de los cambios, enviarían otro archivo “For…”, que sería la back-translation para actualizar con los cambios una vez estén implementados en la forward translation).

El nombre del documento para actualizar comienza por «For…», seguido del código de documento. Le dan a la traducción el mismo código que al original. Esto nos ayudará a identificar, por parejas, cada archivo original con su correspondiente traducción para actualizar.

Los trabajos de track changes se presupuestan por horas y pueden tratarse de proyectos de traducción, de revisión o incluso de adaptación. Se calculan todos los tiempos conforme al procedimiento general o con la ayuda de la calculadora «Cálculo de tiempo de trabajo» TC (Track-changes) disponible en el CRM.

• Tipo de proyectos para TC
  • Proyectos de revisión: habrá que revisar los cambios que ya estarán implementados en la traducción que nos envían. Se calcula el tiempo de revisión (Hour(s) Review).
  • Proyectos de traducción: como todas las traducciones para PSI, se realizarán bajo el proceso de traducción + revisión. Para el presupuesto, calcularemos por separado los tiempos de traducción y de revisión de los cambios marcados y los sumaremos, anotando el total de horas para el encargo (T+R) en una única partida de Hour(s) Translation.

Tanto si calculamos manualmente como si usamos la calculadora del CRM, los tiempos de la fase de traducción y de revisión se redondearán al alza, cada uno por separado. La suma de ambos redondeos es lo que anotaremos en el presupuesto. También hay disponible una calculadora para obtener el tiempo para el traductor/revisor.

• • Proyectos que fusionan traducción de track changes y revisión completa: son proyectos bastante excepcionales. El original contiene cambios marcados que hay que implementar en la traducción y, además, nos piden revisar toda la traducción con su original. El proceso para presupuestar estos proyectos es el siguiente:
    • Contabilizar los TC calculando el tiempo solo de traducción.
    • Contabilizar la revisión conforme al procedimiento general, en base al recuento total del original (TC incluidos). De este modo no cobraremos doble la revisión de los TC.
    • El proceso de trabajo más eficaz será el siguiente: un traductor traduce los TC, un revisor revisa toda la traducción (TC + partes sin TC) con su original. Hay que dejar muy claro al revisor que debe revisar la totalidad del documento (no solo los TC).

Además del propio tiempo de trabajo en los cambios marcados, hay otras cuestiones importantes que debemos considerar en todos los proyectos en la fase de preparación del presupuesto:

Formato de los cambios marcados

Como explicamos en las indicaciones básicas, para PSI es importante que implementemos los TC siguiendo el mismo formato, la misma disposición que tienen en el original. Al recibir el encargo, miraremos en detalle los TC del documento original y, si detectamos alguna parte donde consideremos que será casi imposible replicar el mismo formato, debemos explicárselo al cliente, indicarles qué partes son y consultarles si podemos tachar entero el texto anterior y añadir el nuevo.

Imágenes

Consultar la información del curso en Okodemy “Ejemplo – Edición de imágenes dentro de encargos de traducción”.

Si entre los cambios marcados en un documento encontramos imágenes, puede ser que en la traducción para actualizar no haya ninguna imagen y debamos añadir una, o puede ser que en la traducción ya haya una imagen y haya que modificarla. En primer lugar, buscaremos siempre las imágenes del original dentro de la traducción para determinar qué necesitamos hacer. También nos fijaremos en si hay más imágenes dentro de la traducción para actualizar, y dependiendo de si salen editadas con cuadros de texto o no editables, seguiremos el mismo enfoque si hay que añadir imágenes nuevas.

El cálculo del tiempo para la edición de imágenes se realiza en base a los procedimientos generales. En el caso de proyectos de track changes, el tiempo de edición de imágenes no se incluirá en el presupuesto en una partida de Hour(s) File Preparation. Como estos trabajos se facturan por horas, añadiremos el tiempo correspondiente sumado dentro de Hour(s) Translation. Aunque solo sea una imagen, añadiremos el tiempo que estimemos, tanto de la edición en sí como de la traducción de su contenido.

Índices

Tras actualizar un documento con la función de control de cambios, siempre habrá que actualizar el índice del documento (si lo tiene), sea porque se han añadido o eliminado secciones o por actualizar los números de página. A menudo nos encontramos con índices que ya están rotos en el texto que hay que actualizar y que requerirán trabajo para arreglarlos, así que conviene adelantarnos.

Como comprobación inicial al recibir los documentos, actualizaremos el índice (clic en actualizar campo) en la traducción que tenemos que actualizar, para comprobar si sale bien, si salen todos los apartados que hay actualmente en el texto, o no. Hay que mirarlo de manera pormenorizada.

Si detectamos errores, presupuestaremos el tiempo que nos llevará arreglarlos en nuestro control de calidad final, a razón de 5 minutos por apartado inexistente/que haya que arreglar. Si procede presupuestar tiempo de revisión de formato (porque supere la media hora de trabajo), entonces añadiremos el tiempo de arreglar el índice ahí. Si no tenemos esa partida, lo camuflaremos en la de horas de traducción de TC.

Que el índice se actualice bien en el documento de destino depende, además de su configuración inicial dentro del documento para actualizar, de que se implementen los cambios marcados con el formato adecuado, con cuidado de no romper referencias/marcadores.

Referencias cruzadas

Únicamente para proyectos de track changes en protocolos y manuales del investigador (IB) (o documentos voluminosos similares, donde veamos numerosas referencias cruzadas)

En los presupuestos solamente se incluirá el tiempo de revisar/crear correctamente las referencias cruzadas de las partes con TC (no del resto del documento, ya que se considera Out of Scope).

SOLAMENTE en caso de que el cliente solicite que se realice esa revisión/arreglo de todo el documento se presupuestará aparte. En este caso, el cliente esperará un resultado final en el que todas las referencias coincidan y lleven correctamente donde deben llevar. Podemos encargar esta tarea al traductor/revisor (aclarando que hay que revisar las referencias de todo el documento), externalizarlo a una empresa de preparación de archivos o, si son pocas, ocuparnos de ello internamente.

En estos casos se incluirá en el presupuesto dentro de Hour(s) File Preparation. Para el cálculo del tiempo, ejecutaremos esta macro en el documento original con track changes. Encontraremos aquí las instrucciones para ejecutarla. Se prevé un presupuesto de 1,5 minutos por referencia.

NOTA IMPORTANTE: Si se detecta que hay problemas con las referencias cruzadas en partes Out of Scope, notificar al cliente para que ellos valoren si quieren que lo arreglemos (bajo presupuesto) o no.

Revisión de formato del documento entero

Por defecto, en un proyecto de control de cambios para cualquier cliente únicamente trabajamos en la traducción (o/y revisión) y ajuste de formato de aquellas partes con cambios. Sin embargo, cuando se añaden/eliminan textos en un documento, el resto de apartados dentro del documento ocupan un espacio diferente al inicial y esto puede hacer que requieran algún ajuste de formato para que la distribución sea perfecta. Es por eso que, en algunos proyectos, PSI podría querer que revisemos el formato del documento actualizado completo, revisión que hará la PM durante su control de calidad. Lo habitual es que solamente lo requieran en documentos largos como protocolos e Investigator’s Brochures, o ciertos materiales de pacientes con un formato complejo (tarjetas, diarios). En cualquier caso, se ha acordado con PSI que solamente presupuestaremos y haremos la revisión de formato cuando lo pidan explícitamente en su solicitud. (Si se trata de uno de esos documentos que creemos que querrán revisar, podemos consultarles, pero evitemos presupuestarlo directamente porque debe indicárnoslo el cliente).

Presupuesto

Únicamente si el cliente ha solicitado este proceso, calcularemos el tiempo para el presupuesto. Lo calcularemos en base a una estimación de 2 minutos por página del original (versión con cambios) (3,5 minutos por página en el caso de tailandés) y redondearemos al alza, por medias horas. Se realizará sin coste adicional hasta media hora de trabajo (incluida). Por encima de media hora, se presupuestará en una partida de Hour(s) File Preparation.

Si el proyecto es FWT+BT, no olvidemos presupuestar el tiempo de revisión de formato en cada presupuesto (para la FWT y para la BT). (Como el cálculo es solo una estimación, podemos poner lo mismo).

En documentos muy largos podríamos encontrar mayores problemas que solucionar (referencias cruzadas, por ejemplo, en cuyo caso habría que avisar al cliente para preguntar si quieren que lo presupuestemos). Si a la hora de arreglar el documento vemos que nuestra estimación se quedó corta, enviaremos al cliente el presupuesto actualizado (Correction) con el tiempo que nos haya llevado.

Proceso

Aunque el cliente enfoque un proyecto bajo el proceso de track changes, en algunas ocasiones podrían revisar internamente la versión en limpio que obtengan de nuestro archivo actualizado, aceptando los cambios, ya que al fin y al cabo esa acabará siendo la versión final una vez se aprueben esos cambios. El formato del documento actualizado debe ser lo más similar posible al del original en limpio. Si el cliente lo envía, lo usaremos como referencia para la revisión, por ejemplo, para comprobar el espacio entre los apartados u otras cuestiones que son más difíciles de advertir en el original con cambios. Si no lo envían, podemos hacer una copia de la versión con TC y aceptar los cambios.

Revisaremos el formato en el documento actualizado con los cambios, ya que ese será el archivo que entreguemos (no se entregan versiones en limpio a menos que lo pidan). En el proceso, podemos hacer clic en la línea vertical que nos permite ocultar y mostrar los TC, para visualizar cómo quedará la versión en limpio.

También, al finalizar podemos hacer una copia en limpio del archivo retocado y realizar una comprobación final.

El formato se dejará lo más parecido/equivalente posible al original en limpio:

• Eliminar dobles espacios.
• Añadir alguna línea en blanco adicional entre apartados si consideramos que es mejor que un apartado comience en la siguiente página (o lo contrario, eliminar espacios sobrantes).
• Ajustar los márgenes del texto dentro de celdas de tablas para que todo el texto se lea.
• Ajustar gráficos o cuadros de texto.
• Cambios en negritas/cursivas/otros formatos para que coincidan con el original en limpio.
• Garantizar que el título/nombre de una tabla aparece en la misma página que la propia tabla o, si no entra en la página, que queden ambos juntos en la página siguiente, etc.
• Actualizar el índice (el campo automático) cuando ya tengamos todo listo. Asegurarnos de que aparecen todos los apartados correctamente y que coincide con el índice del original actualizado. ¡¡¡IMPORTANTE!!!: En nuestra revisión de formato, solo incluimos dicha actualización automática. Si hay errores, debemos solucionarlos, sin coste adicional si se deben a no haber agregado correctamente las referencias cruzadas/los cambios marcados. Si son por causas ajenas o porque los problemas se arrastran del target anterior*, antes de proceder le explicaremos al cliente lo antes posible que necesitaremos presupuestar el tiempo que lleva arreglarlo. Independientemente de la causa, podemos externalizarlo a F, que apenas tarda en arreglarlo. NOTA: Para adelantarnos a potenciales errores en el índice, recordemos realizar esta comprobación durante la fase de presupuesto.

* Salvo si el target anterior lo tradujimos nosotros, ya que será responsabilidad nuestra.

Lo esperable es que la traducción previa ya tenga un formato equivalente y no se requieran más que algunos pequeños ajustes de espaciado/distribución de apartados o de tablas. En todo caso, haremos todas las comprobaciones. No importa que esos cambios de formato no aparezcan en el original con TC que se usó para la solicitud; en cualquier caso, prevalece el formato del original en limpio.

Todos los ajustes de formato los haremos también con la función de control de cambios activada.

Certificado

NOTA: las siguientes directrices no aplican a documentos para EE.UU. Ver aquí.

El certificado no se prepara en todos los proyectos, sino cuando lo piden. Prepararemos el certificado correspondiente (traducción/revisión/adaptación), específico de TC, con la mención de haber trabajado solamente en las partes con cambios marcados.

Aplican las directrices generales para los certificados. El nombre del archivo para el certificado (dentro) será el del documento original con track changes. El nombre del propio certificado (fuera) será el del documento target, es decir, acabado en código de idioma target, seguido de _CoT (o CoR en caso de certificados de revisión). En el caso de proyectos de back-translation, ver aquí.

Si en cualquier proyecto piden de manera puntual un certificado completo (full CoT), podríamos emitirlo con seguridad porque, al tratarse de un proceso de track changes estándar, habremos traducido y revisado todo el contenido, tanto la base, en el proyecto inicial, como las sucesivas actualizaciones estándar.

Si nos encontramos ante un proyecto de track changes “no estándar” o un documento que en el pasado pasó por alguna actualización “no estándar”, ver a continuación cómo proceder.

Track changes «no estándar»

En ocasiones no utilizamos los track changes porque se trate de una enmienda convencional, porque se haya actualizado un documento en particular, sino en proyectos donde el cliente tiene que traducir un documento diferente/nuevo pero, por motivos de eficacia o para reducir plazos/costes, comparan documentos similares para poder reutilizar traducciones previas. Ejemplo: un Adult ICF de un centro de estudio con un Adult ICF de otro centro de estudio.

Los proyectos de TC no estándar implicaban una reutilización consecutiva de los documentos que ponía en peligro la calidad de las traducciones, de las partes sin TC. PSI se ha comprometido a utilizar TC únicamente en proyectos estándar, cuando haya actualización de un mismo documento a una versión posterior. Es decir, si nos encontramos con TC no estándar, será de manera excepcional.

En proyectos no estándar, no hay problema en emitir un CoT específico de TC. El problema es que, debido a la finalidad real de traducir un documento nuevo, lo más habitual es que pidan un certificado normal (full CoT). Se acordó con PSI que siempre que soliciten un full CoT en proyectos de TC no estándar, tendremos que revisar el documento completo (full revision) una vez actualizado. También si se trata de TC no estándar con documentos para EE.UU.

Full revision

Presupuesto

En el presupuesto se añadirán por separado la inclusión de los cambios y la revisión del documento entero. Los TC constarán como Hour(s) Translation y la revisión se presupuestará aparte como Hour(s) Review.

Para calcular el tiempo de los track changes, calcularemos solamente el tiempo del paso de traducción (no T+R), puesto que la revisión la calcularemos aparte para el documento entero (TC incluidos). El proceso de trabajo será: traducción de TC + revisión del documento completo.

La revisión del documento entero se calcula en base al recuento de palabras del documento original en limpio (aceptando los cambios), y se redondea al alza por medias horas.

En proyectos de back-translation (sola) se calcula exactamente igual. En proyectos de FWT+BT, para calcular el tiempo de revisión para la BT sumaremos 10% al total de palabras del original en limpio, aceptando los cambios y calcularemos el tiempo de la revisión en base a ese dato.

Sin embargo, tanto el tiempo de TC como de revisión se habrán calculado en base a una FWT que aún no tenemos. Además, si durante la revisión de la FWT se producen muchos cambios fuera de las partes con TC, aumentará el número de cambios que habrá que implementar en la BT y el tiempo de TC será superior al que se presupuestó. No hay problema. Como veremos a continuación, los únicos cambios que debemos hacer durante la full revision son para corregir diferencias de contenido y errores, así que no se espera que haya demasiados cambios. En cualquier caso, se podrá actualizar el presupuesto de la BT una vez tengamos lista la FWT.

Instrucciones

Hay que limitar las correcciones de la full revision a errores/diferencias de contenido y evitar los cambios preferenciales, puesto que las versiones anteriores ya quedaron aprobadas y en principio solo han de actualizarse con los cambios marcados. Indiquemos al revisor que añada comentarios si encuentra cualquier cuestión preferencial, pero que no haga cambios en el texto.

Aparte de corrección de errores y diferencias de contenido, veamos qué podemos hacer y qué no. Se usa un ejemplo de FWT+BT solamente porque abarca más supuestos:

• Formato: SÍ debemos revisar el formato de los documentos y hacer que queden iguales, que los originales coincidan con las FWT y las FWT coincidan con las BT. Atención especial a los saltos de página, que pueden pasarse inadvertidos en la versión con TC y pueden requerir modificaciones para que original y traducción queden iguales.
• Consistency: si los textos requieren un par de cambios puntuales por cuestiones de coherencia terminológica, PSI nos permite hacerlos, pero solo si son verdaderamente mínimos (ej. un par de términos a lo largo del documento).

Si el traductor detecta una mayor falta de coherencia a lo largo de un documento o incluso entre los diferentes documentos que hay que actualizar en la solicitud, debe avisarnos cuanto antes y habrá que consultar a PSI cómo quieren proceder. Dependiendo del proyecto en cuestión, pueden preferir que realicemos todos los cambios que veamos convenientes para mejorar la coherencia o que no hagamos ningún cambio. Nos han dejado claro que NO debemos tomar la decisión por nuestra cuenta.

Si el traductor/revisor ha realizado cambios que no debe y no hubiera tiempo de consultar con PSI, revertiremos dichos cambios y añadiremos comentarios.

• Ortografía: debemos corregir errores ortotipográficos, pero NO otras cuestiones. Por ejemplo, el uso de las mayúsculas es algo que el traductor debería haber decidido en el momento de la traducción inicial de esos documentos. En fases posteriores de actualización con TC es tarde para plantearse mejoras en ese sentido.

De cara a los propios cambios marcados que hay que añadir en el documento, el traductor/revisor no necesariamente calcará las mayúsculas del documento original, sino que decidirá, en primer lugar, basándose en lo que se haya hecho en otras partes de la traducción que se está actualizando (por coherencia) y, en segundo lugar, siguiendo en las normas oficiales en el idioma en cuestión o/y la práctica común en ese tipo de textos. Esto aplica tanto a FWT como a BT; en BT tampoco se calcarán las mayúsculas de las FWT necesariamente.

Proceso

La full revision se hará, por supuesto, con control de cambios activado. La traducción de los cambios marcados se registrará con el nombre de usuario «Translator» y las correcciones fruto de la full revision con «Reviewer», para que el cliente pueda aislar los cambios de uno y de otro, si lo necesita. Además, puede haber un tercer nombre de usuario que corresponda a Okodia.

Sin embargo (y esto es algo que ya hemos advertido al cliente), hay que tener en cuenta que entre todos los cambios que pueda hacer el revisor no será posible aislar los que son en partes de TC y los que son fruto de la revisión del resto del documento.

Es importante explicarle al revisor el proceso que debe seguir y las siguientes instrucciones. El revisor revisará el documento entero, todo seguido, tanto las partes que contienen TC como las que no, y hará los cambios que sean necesarios en todas partes, pero con un matiz importante: en los TC puede realizar todas las correcciones que considere adecuadas, y en las partes sin TC solo las que sean verdaderamente necesarias (errores o diferencias de contenido), añadiendo un comentario si encuentra alguna cuestión preferencial.

En caso de una BT, esta contendrá todos los cambios que haya en la FWT, independientemente de si responden puramente a los TC del original o también son fruto de la full revisión (salvo la excepción comentada del uso de mayúsculas, que se determinará en base a los criterios relevantes).

El orden habitual de estos proyectos será realizar por completo la fase de FWT (traducción + full revision) y solo entonces se procederá a la BT. Así, todos los TC que hayan surgido en todas las fases de la FWT son los que incluirá el traductor de la BT.

Si surge cualquier imprevisto en el proyecto que requiera alterar ese orden (por ejemplo, que por urgencia o cualquier otro motivo, el cliente nos solicite trabajar primero en la FWT+BT de los TC y posteriormente hacer la full revision de ambas), complicará el proceso porque implicará pasos adicionales, yendo hacia delante y hacia atrás entre traductor y revisor. Es importante explicarle esto al cliente porque a menudo no lograremos acortar el plazo sino todo lo contrario.

Control de calidad y entrega

IMPORTANTE

En cualquier proyecto de track changes (TC/cambios marcados) no se pueden realizar cambios out of scope, en partes del texto que no tienen cambios en el documento original. Si encontramos una errata o cualquier otro elemento que desearíamos modificar, añadiremos un comentario para informar al cliente.

Tampoco se debe realizar ningún cambio sin marcarlo con control de cambios. Para evitar que esto pueda ocurrir, y a raíz de una incidencia en una entrega (Incidencia #153), decidimos implementar una comprobación adicional para confirmar que ningún traductor realice modificaciones en la traducción sin marcarlas con TC. Se hará inmediatamente al comenzar VER, antes de revisar los cambios en el documento actualizado:

1. 1. Hacer una copia del documento actualizado entregado por el revisor.
   2. En ella, se rechazan todos los TC y se guarda el archivo.
   3. Se compara este archivo con el “For…” inicial que envió el cliente, en Word (menú Revisar > Comparar).
   4. Si no salen cambios, significa que no hay cambios out of scope no marcados. Procederemos a realizar nuestro VER sobre el documento actualizado que envió el revisor.

Si salen cambios, son modificaciones que se hicieron sin TC activado. Miraremos si esos cambios aparecen ya en la versión que entregó el traductor o si los realizó el revisor, para pedir explicaciones a la persona pertinente. Le recordaremos que no se deben realizar cambios out of scope que no aparezcan en el original con TC ni realizar ningún cambio sin TC activado. Debemos consultarle si alguno de esos cambios que añadió son verdaderamente necesarios porque corrijan errores o diferencias de contenido, en cuyo caso esos sí deberíamos sugerírselos al cliente, pero no modificando directamente el texto sino añadiendo un comentario.

Una vez aclarado el tema, realizaremos nuestro VER sobre el documento actualizado que envió el revisor, pero en él tendremos que corregir todos aquellos puntos donde se realizaron cambios sin marcar y volver a dejar el texto original (o bien pedirle a quien realizase estos cambios que haga las correcciones necesarias en el documento que entregó).

• Cambios marcados

Nos aseguraremos de que se hayan añadido con autor anónimo. Si el traductor o revisor no cambió su nombre de usuario, en este artículo encontraremos soluciones para corregirlo. IMPORTANTE: Se describen varios modos de anonimizar el autor. En el artículo se advierte que uno de ellos hay que evitarlo con PSI, por el motivo que se explica.

• Comentarios

Si el lingüista añadió comentarios, también deben quedar anónimos. Además, como en cualquier proyecto, los leeremos para valorar si son relevantes para el cliente o conviene borrar alguno y nos aseguraremos de que su contenido sea comprensible para el cliente y esté redactado de manera genérica y hablando en plural, como empresa.

• Rastro del revisor

Recordemos “borrar el rastro” del revisor.

El texto que añada debe quedarse marcado. El texto que elimine, si es porque en el original se elimina y al traductor se le pasó por alto hacerlo, también. El texto que elimine dentro de los cambios realizados por el traductor (en otras palabras, correcciones que haga sobre el trabajo del traductor) no debe quedar visible (aceptamos ese cambio), ya que al cliente solo queremos ofrecerle la traducción final revisada que vemos conveniente, no versiones incorrectas.

Habitualmente somos capaces de detectar el rastro del revisor a simple vista, pero para mayor certeza, podemos filtrar y visualizar solo sus cambios, en el menú Revisar > Seguimiento > Mostrar revisiones > Personas específicas, y dejar marcado solo al revisor.

Si filtramos de este modo, igualmente es conveniente ver en paralelo una copia de la traducción actualizada donde se vean todos los cambios, para ver todas las correcciones en contexto y poder actuar con mayor seguridad sobre los cambios del revisor que haya que aceptar.

• Pie de página

Actualizaremos la fecha de la traducción por la fecha en que entregaremos el documento actualizado. En documentos para pacientes (solamente en esos casos) habrá que añadir el status de la traducción en el pie de página. Si la traducción que nos envían para actualizar ya tiene un determinado status, al actualizar el documento, cambiaremos siempre el status a “Draft”. Al modificar algo del contenido de un documento, el cliente ha de revisarlo, así que el status vuelve a ser de borrador.

Todos los cambios que requieran los footers se harán también con control de cambios activado.

• Nombre del archivo

Hay que cambiar el nombre del archivo actualizado antes de devolverlo. Se actualiza usando el filename del original. De ese modo, el documento target quedará con versión y fecha actualizada…

… filename del original, pero cambiando el código de idioma source por el target.

Ejemplo ES>EN:

ORIGINAL → 1271OKD_ABC-222_Main ICF_version 8.0_20Aug2021_ES-MX_redline

TRADUCCIÓN → 1271OKD_ABC-222_Main ICF_version 8.0_20Aug2021_EN_redline

Excepción: en el caso de trabajos de TC en back-translations, no se cambia el código de idioma source por el target. Ver cómo nombrar los archivos en el caso de Back-translations.

• Notas

Si al final del nombre del archivo original se menciona «_redline», usaremos «_redline» en el archivo de destino. Si aparece “TC”, usaremos “TC”. PSI acostumbra a usar “redline” más que “TC”. Excepción: no se añadirá “redline” ni “TC” en documentos para EE. UU.

Solamente entregaremos el documento actualizado con TC, no la versión en limpio (salvo si lo piden en algún proyecto puntual).

• Certificado

Se preparará, solo si lo solicitan, siguiendo las directrices acordadas.

Back-translations

A continuación se explican las particularidades de la gestión de back-translations de manera específica para PSI pero, para información general, consulta los procedimientos generales de PM y el ejemplo práctico “Ejemplo – Gestión de Back-translation” disponible en Okodemy.

Para PSI realizaremos back-translations principalmente de documentos dirigidos a pacientes.

Podemos recibir solicitudes solo de back-translation, que se registran y presupuestan como haríamos con una traducción directa, o del proceso completo (FWT+BT), que se explica a continuación. El cliente solicita a la vez los dos pasos, que realizaremos en ese orden, y los archivos resultantes de ambos pasos se entregan juntos en la fecha de entrega final (no quieren entrega parcial de la FWT, a menos que lo pidan de manera puntual).

Para este proceso de dos pasos, PSI enviará cada archivo original (en inglés) nombrado como de costumbre pero con doble código; el primero es el código para identificar la FWT y el segundo, para la BT. En la entrega, usaremos solamente el primer código para nombrar la FWT y el segundo código para la BT.

El archivo de la FWT lo nombraremos como el original (usando el primer código), acabado en código de idioma de destino.

El archivo de la BT lo nombraremos como el original también (pero usando el segundo código), acabado en código de idioma de la FWT + “_back-translation”. Dicho de otro modo, el nombre de la BT será el mismo que el de la FWT (a excepción del código), añadiendo “_back-translation” al final. La BT mantiene el código de idioma de la FWT porque, como la BT será siempre en inglés, PSI no busca añadir el código del idioma real (EN) sino saber de qué idioma es back-translation. Ejemplos en cada subapartado.

Presupuesto

Nombrado de archivos

En los presupuestos (en Plunet) debemos nombrar los archivos de la siguiente manera:

PSI envía:

1022OKD-1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_EN

Hay que preparar un presupuesto para la FWT y otro para la BT. Los nombres de los archivos en cada presupuesto serán los del documento original de cada proyecto:

Presupuesto de la FWT (_EN al final porque el source de la FWT es inglés):

1022OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_EN

Presupuesto de la BT (_ES-US al final porque el source de la BT, aunque aún no lo tengamos disponible, será ES-US):

1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US (back-translation)

¡OJO! En el último ejemplo vemos que se indica “back-translation” entre paréntesis al final del nombre de archivo. No hay que añadir _back-translation al final de cada archivo. Necesitan ver el nombre de archivo exacto + código de idioma.

“Back-translation” se debe añadir al final del todo y entre paréntesis, para aclarar qué tipo de servicio es, no como parte del filename. Si la solicitud comprende más de un archivo, los anotaremos todos unidos con + y añadiremos “(back-translation)” al final del todo.

Lo registraremos de este modo en el campo Project name, y de ahí pasará igual al item y a la factura.

Proceso

Crearemos 2 quotes, uno definitivo (como los habituales) para la forward translation y otro provisional para la back-translation. Ambos quotes se enviarán a PSI para pedir su confirmación de ambas fases. En los presupuestos, cada documento se llamará con su correspondiente código, el de FWT o BT (no con el código doble como lo envía PSI). Habrá una fecha de entrega final para ambas fases. No habrá entrega parcial de la FWT, a menos que PSI lo pida específicamente.

Darán su aprobación para la FWT y la BT desde el principio, en base a los presupuestos enviados. Para la BT, el presupuesto inicial es una estimación, puesto que aún no tenemos la FWT real que será el documento original de la BT. Para el recuento de la BT, seguiremos nuestro procedimiento general de Gestión de Proyectos: total de palabras del documento original + 10% por potencial expansión del volumen en el idioma de la FWT. Si el proyecto es de track changes, contabilizado por tiempo, para la BT sumaremos 10% al tiempo calculado para la FWT.

Es un cálculo estimado. Una vez tenemos lista la FWT, analizaremos el documento y actualizaremos el presupuesto con el recuento o la estimación de tiempo reales.

Esta actualización de presupuestos de BT es parte del procedimiento habitual con este cliente, así que no es necesario crear una Correction del presupuesto; modificamos directamente el presupuesto inicial enviado. Se actualizará el presupuesto y, entonces, pasaremos de Quote a Order. Recordemos guardar en la carpeta source de la Order los documentos originales que antes no teníamos, es decir, la FWT.

No se enviará el presupuesto actualizado hasta el final, con la entrega. Si el presupuesto inicial no sufre cambios (en ocasiones ocurre en trabajos de TC), se lo indicaremos al cliente en la entrega.

NOTA: este apartado describe el desarrollo del proceso completo de FWT + BT por ser el más complejo. En solicitudes solo de BT, que contamos de inicio con la FWT que hay que traducir, el presupuesto inicial ya es el definitivo y se calcula como si de cualquier traducción normal se tratase.

Entrega

Nombrado de archivos

PSI envía:

1022OKD-1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_EN

Okodia entrega:

FWT: 1022OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US

BT: 1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US_back-translation

Footers

En cuanto al footer de la BT, será el mismo que el de la FWT pero añadiendo debajo la línea relativa a la BT.

Ejemplo de footer de la FWT:

Protocolo Nº.: ABC-222

Formulario de Consentimiento Informado Principal, versión 2.0 de 22 de julio de 2021

Borrador de traducción de inglés a español (US) de 24 de agosto de 2021

Ejemplo de footer de la BT:

Protocol No.: ABC-222

Main Informed Consent Form, version 2.0 dated 22 July 2021

Draft translation from English to Spanish (US) dated 24 August 2021

Draft back-translation from Spanish (US) into English dated 24 August 2021

Todos los documentos destinados a pacientes deben reflejar el estatus de “Draft” (o en el idioma de destino correspondiente) dentro del pie de página. También aplican el resto de directrices relativas a pie de página.

En procesos donde hacemos los dos pasos seguidos (FWT+BT), ambos documentos tendrán la misma fecha de traducción (aunque no sea real), que será la fecha de entrega.

Como se muestra en el ejemplo anterior, puesto que la forward translation es a una variante específica, se incluye la variante source en la línea de la back-translation, como excepción respecto a la norma general de no especificar la variante source.

Proceso

Al finalizar ambos pasos, cuando tengamos lista la FWT, la BT y el potencial presupuesto de BT actualizado, entregaremos a PSI todos los materiales a la vez.

Es habitual que PSI realice una posterior revisión interna de dichos documentos, para asegurarse de que la FWT y la BT estén alineadas y ambas sean fieles al original, y que nos envíen los documentos con algunos cambios o sugerencias que habrá que consultar con el equipo de traducción. Ver más información en el apartado «Revisión de sugerencias del cliente».

Cuando finalice esta fase y PSI envíe (o tengamos nosotros ya, tras atender sus sugerencias) las versiones finales de FWT y BT, actualizaremos en el footer el estatus de “draft” a “final” (en el idioma de destino correspondiente) y la fecha de finalización la indicará PSI o la incluirán ellos directamente en el footer de los documentos que nos envíen, y será la misma fecha para FWT y BT. Será esta fecha de finalización la que indicaremos en el campo de fecha de traducción si solicitan un certificado de traducción.

Si el proceso de FT+BT no se realizó de seguido, sino que realizamos la FWT en el pasado y más adelante se solicita la BT, la fecha de ambas traducciones lógicamente no coincidirá. En el footer de la BT indicaremos la fecha real que corresponda. Sin embargo, si la FWT quedó sin revisar por parte de PSI, hasta que estuviera la BT, tras su comprobación de ambos documentos juntos, es posible que PSI decida cambiar la fecha de la FWT y en el footer de FWT y BT pongan la misma fecha de finalización. En todo caso, esto es algo que normalmente hará PSI internamente.

Certificados de traducción

Si los solicitan al finalizar, los nombres de archivo tanto para dentro como para fuera del certificado seguirán las directrices generales de certificados de este cliente, seguido de _back-translation_CoT. (A priori la herramienta del CRM de elaboración de CoT lo añadirá por sí sola.)

NOTA: Como excepción a la norma de no especificar variante source, en el caso de back-translations, en el certificado sí añadiremos el idioma original con su variante específica.

Ejemplos de certificados para un proyecto EN>ES-US:

Original:

1022OKD-1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_EN

FWT – Nombre de archivo para el CoT (dentro):

1022OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_EN

FWT – Nombre del propio CoT (fuera):

1022OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US_CoT

BT – Nombre de archivo para el CoT (dentro):

1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US

BT – Nombre del propio CoT (fuera):

1023OKD_ABC-222_Main ICF, version 1.0 dd. 21-May-2021_ES-US_back-translation_CoT

La fecha del documento (Document date) para el certificado de la BT será la fecha de traducción de la FWT y no la del documento source inicial. Dicha fecha se encuentra en los footers/headers específicos de PSI o es la fecha de entrega de la FWT en traducciones para Estados Unidos.

En materiales dirigidos a pacientes, la fecha de traducción final es la que hay que tener en cuenta.

Trabajos de track changes

También realizamos trabajos de track changes en el marco de proyectos de back-translation (para actualizar con cambios solo la back-translation o tanto la FWT como la BT). Todos los procesos descritos relativos a back-translations son también aplicables en proyectos de track changes. El sistema para nombrar los archivos será idéntico, solo que en el nombre del documento original aparecerá _redline al final, así que pasará también al nombre de la back-translation (_idioma_redline_back-translation).

En estos proyectos, también habrá que seguir las directrices relativas a trabajos de track changes.

Revisión

Nos referimos a proyectos únicamente de revisión, ya sean bilingües o monolingües, es decir, podríamos recibir el documento para revisar junto con su correspondiente documento original o sin él. No son proyectos muy frecuentes.

Normalmente solicitan revisión bilingüe de una traducción, para revisar comparándolo con el original. Es muy raro que nos soliciten una revisión monolingüe así que, si el cliente solo envía el documento para revisar, sin ningún documento original, conviene reconfirmar con ellos si necesitan revisión monolingüe o se les olvidó adjuntar el original.

Indicaciones generales

• Se contabiliza por horas y conforme al procedimiento general de PM. Mientras que la fase de revisión de cualquier proyecto T+R se calcula conforme a alta calidad, los tiempos para los proyectos únicamente de revisión los calculamos conforme la calidad estándar. Excepción: ver apartado Revisión no estándar.
• Se entregará el archivo revisado en limpio, no con cambios marcados (salvo si lo piden de manera puntual).
• Solo podemos realizar correcciones de errores o de diferencias de contenido (a diferencia de la fase de revisión de cualquier proyecto T+R, donde el revisor puede realizar cualquier corrección o mejora que considere). Podemos indicar cualquier otro aspecto más preferencial añadiendo un comentario. Compartiremos esta indicación con los revisores en todos los encargos de revisión.
• PIE DE PÁGINA: Si existe un original, añadiremos al documento revisado el PSI footer y seguiremos todas las directrices habituales para el pie de página. Además, no hablaremos de “Review” sino de “Translation from X to Y”. Si no existe original, consultar con el cliente si añadimos PSI footer y si indicamos “Translation” o “Review”.
• FILENAME: Si existe un original, los nombres de los archivos seguirán las indicaciones generales del cliente, las mismas que para proyectos de traducción. Se renombrará el archivo revisado conforme al original (acabado en código de idioma de destino). Si no hay original, se mantiene el nombre de archivo existente.
• CERTIFICADO: Si piden certificado, se preparará un Certificate of Review (CoR). Si la revisión ha sido solo sobre cambios marcados, se emitirá un CoR con la leyenda que indica que solo hemos revisado los cambios. Excepción: ver apartado Revisión no estándar. Si hay duda entre estándar/no estándar, consultar abiertamente al cliente qué tipo de certificado prefiere, ya que suelen mencionar “CoT” como sinónimo de todo tipo de certificados, pero podrían requerir un CoR. Si en algún proyecto puntual piden un CoT, podremos emitirlo mientras hayamos revisado la totalidad del documento. Para el certificado, también se usará el filename del original (cuando lo haya).

Revisión no estándar

La intención real detrás de algunos proyectos es la de traducir el archivo original que envían reutilizando otra traducción que es «similar«, por lo que solicitan su revisión y que hagamos los cambios que sean convenientes para que coincida con el contenido del original.

Otras veces nos envían varios documentos para traducir, que son muy similares entre sí, y nos piden traducir uno de ellos y usar esa traducción y revisarla con cada uno del resto de originales para “obtener” de ese modo el resto de traducciones. Se entiende de nuevo que su intención real es traducir todos los documentos, pero el proceso de revisión se escoge solo por su relevancia a nivel de productividad/plazos/costes.

¡OJO! Solamente aceptemos trabajar en el proyecto bajo el enfoque de revisión en los casos en que la PM valore que original y traducción tienen un alto grado de similitud, sobre todo a nivel estructural, de formato. Si no, se les indicará que lo conveniente es traducir el documento original desde cero.

En el caso de revisiones no estándar, se siguen las indicaciones generales para revisiones mencionadas anteriormente, salvo por dos excepciones:

• Este proceso de revisión no es tan productivo como una revisión al uso, sino que se espera que haya diferencias de contenido más significativas, por lo que a criterio de la PM, podrá calcular el tiempo de revisión usando la ratio de revisión de CTA, calculando en base al recuento de los originales, si los tenemos (si son PDF, de su OCR).
• Dado que la intención real es traducir esos documentos, se preparará un Certificate of Translation (CoT). No hay problema: mientras se haya revisado la totalidad del documento (o de la traducción que sirva como base), se podrá certificar como traducción.

Más información relacionada con revisión no estándar en el apartado Enfoques alternativos en proyectos de traducción por sugerencia del cliente.

Otros proyectos relacionados con revisión

En ocasiones recibimos solicitudes que fusionan track changes y revisión. El original contiene cambios marcados que hay que implementar en la traducción y, además, hay que revisar toda la traducción con su original. El enfoque más apropiado para presupuestar estos proyectos es el siguiente:

• Contabilizar los TC calculando el tiempo solo de traducción.
• Contabilizar la revisión conforme al procedimiento general, en base al recuento total del original (TC incluidos). De este modo no cobraremos doble la fase de revisión de los TC.
• El proceso de trabajo más eficaz será el siguiente: un traductor traduce los TC, un revisor revisa toda la traducción (TC + partes sin TC) con su original. Hay que dejar muy claro al revisor que debe revisar la totalidad del documento (no solo los TC).
• Es un proyecto de revisión pero también de traducción (los TC), así que en estos proyectos consultemos al cliente si necesitan un CoT o un CoR. No hay problema en emitir un CoT, porque hemos revisado el documento entero.

Si surgen otras solicitudes de revisión más complejas o peticiones del cliente que puedan ser conflictivas a nivel de certificación, consulta con un supervisor para poder valorar cómo interesa proceder.

MTPE

Podemos hacer traducción automática + posedición si nos lo solicitan expresamente pero debemos tener en cuenta lo siguiente:

• Aplicaremos el listado de tarifas MTPE del cliente. No hay descuento por 100% fuzzies ni por repeticiones, es decir, estos se tarifican con el mismo coste que la palabra nueva. No obstante, esto ya se aplica así de forma automática al seleccionar el listado de tarifas.
• El coste de MTPE solamente incluye la tarea de posedición.
• Para cualquier trabajo de MTPE que nos soliciten, aplicaremos un cargo de preparación de archivos de 7 minutos por documento redondeando en cuartos de hora y con un mínimo de 0,5 h. Estos 7 minutos se han calculado como 5 minutos de revisión del documento + 2 minutos de creación del footer.
• Cualquier otra tarea adicional que se solicite, como por ejemplo la conciliación de traducciones también se tarificará aparte utilizando el listado de tarifas estándar de T+R.
• A menos que el cliente indique lo contrario, debemos trabajar con la versión DeepL Pro Advanced. Es la versión que ya tenemos como plugin de Trados. En caso de querer o necesitar utilizar otro motor u otra versión debemos solicitar autorización previa a PSI.
• La norma ISO que se aplica es la ISO18587, y bajo ningún concepto podemos hacer pasar estas traducciones como ISO17100.
• No haremos MTPE si quieren que bloqueemos 100% fuzzies y /o repeticiones. Si quieren que las bloqueemos, ofreceremos traducción humana. Si hacemos MTPE será sin bloquear segmentos.
• En este email se incluye toda la comunicación e información que se ha enviado al cliente al respecto del uso de IA.
• Documentos con filenames: por el tipo de traducción que el cliente nos pide, los filenames no pueden traducirse mediante MTPE y requieren traducción exclusivamente humana por lo que para poder realizar MTPE en la parte del documento que no tiene filenames y humana en la parte del documento que los contiene, debemos “romper” el archivo y tratarlo de forma separada (parte central vs. parte de filenames). Por este motivo, se añadirá un cargo de preparación de archivos adicional por esta manipulación especial de 7 minutos por documento redondeando en cuartos de hora y con un mínimo de 0,5 h. Ver cómo proceder en curso MTPE para PSI [PMM] de la Okodemy.
• Documentos con referencias/bibliografía: se le indicará al cliente que las traducciones se entregarán en el idioma de destino y no bilingües como solicitan en traducción humana. Normalmente, lo aceptan sin problema. Si la requieren en bilingüe habrá que separar el documento tal y como se hace con los documentos con filenames añadiendo el cargo de preparación de archivos adicional por esta manipulación especial de 7 minutos por documento redondeando en cuartos de hora y con un mínimo de 0,5 h.

Certificates of Translation (CoT)

Los trabajos de MTPE se rigen por la ISO18587, por lo que el CoT que habrá que utilizar es el específico de MTPE que hay en el CRM.

Es importante recalcar que los certificados actuales certifican la traducción en su totalidad, por lo que en el caso de que un documento se realice parcialmente con traducción humana y parcialmente con MTPE, no podremos generar el CoT de forma única, sino que habrá que generar diferentes CoTs donde se especifique qué se certifica con una ISO y qué se certifica con otra ISO. [Puesto que actualmente PSI todavía se encuentra en proceso de pruebas y no sabemos qué CoTs pueden llegar a pedir en procesos mixtos, cuando esto ocurra por primera vez, comentémoslo.]

Adaptación

Por procedimiento general, las adaptaciones son un servicio monolingüe, pero lo acordado con PSI para sus proyectos de adaptación es que por defecto implicarán adaptación + revisión. En todo caso, podría haber distintos tipos de proyecto, siendo el más frecuente y estándar (con PSI) el primero:

• Cuando el cliente solicita solamente adaptación, lo habitual es que envíen el texto para adaptar y un original. Aunque el cliente solo mencione “adaptación”, siempre que recibamos un original habrá que hacer la adaptación de la traducción de una variante a otra y, también, revisar su contenido comparándolo con el original. Si se encuentra alguna diferencia de contenido (es esperable), habrá que actualizar la traducción para que coincida con el contenido del original. Se presupuesta usando la ratio de adaptación + revisión.

El motivo de este proceso estándar para PSI es el siguiente. Las adaptaciones normalmente no las solicitan porque el promotor requiera una adaptación, sino porque necesitan traducir un documento para el que ya tienen una traducción en una variante distinta, que consideran relevante utilizar. La revisión con el original es parte del proceso porque en ese original podría haber ciertas diferencias con la traducción existente, debidas precisamente al cambio de variante: referencias locales, distintos sistemas de medidas o de temperaturas, etc. Hay que ser fieles al original y añadir en la traducción todas esas pequeñas diferencias que puedan faltar. La ratio de adaptación + revisión ya se ha calculado contando con estas potenciales diferencias.

• Si solo envían el texto para adaptar sin un original, antes de preparar el presupuesto debemos reconfirmar con el cliente si verdaderamente solo quieren una adaptación monolingüe y no existe un original, porque PSI no suele requerir este tipo de adaptación. Si lo confirman, se presupuestará usando la ratio de solo adaptación. Será algo muy excepcional con PSI y que se sale del procedimiento acordado para adaptaciones, por lo que habrá que consultar qué necesitan de cara al filename del documento adaptado y si en el footer hablamos de «Translation from English to…» o, esta vez, de «Adaptation from X to Y».

• Similar a como ocurre en los proyectos de revisión, podemos recibir solicitudes que fusionen track changes + adaptación. Esto es simplemente porque, en algunos casos, las diferencias que habrá entre original y traducción las marcan en el original para facilitar su seguimiento. Como la ratio de adaptación + revisión ya se ha calculado contemplando las posibles diferencias, presupuestaremos estos proyectos como cualquier otro de adaptación + revisión, es decir, no contabilizaremos los TC aparte. Sin embargo, si finalmente el tiempo dedicado es superior al que estimamos en el presupuesto, PSI está abierto a que en la entrega enviemos el presupuesto actualizado.

• También podrían solicitar traducción + adaptación: traducir un documento a un idioma y posteriormente adaptar dicha traducción a otra variante. En estos casos, el proceso de revisión no lo realizará la persona que adapte, que normalmente revisa y adapta a la vez, sino que necesitamos revisar la primera traducción. Por lo tanto, posteriormente se realizará únicamente la adaptación. Se presupuesta T+R de la traducción (como de costumbre) y la adaptación usando la ratio de solo adaptación.

Indicaciones generales

• En Plunet, todas las adaptaciones se registrarán bajo el tipo de servicio de Adaptation y el tiempo que se calcule se añadirá en una partida de Hour(s) Adaptation. Aunque exista un original en inglés, registraremos los proyectos como Adaptation, con los idiomas reales de la adaptación, incluyendo ambas variantes (también en source. Se trata de una excepción a la norma).

En Plunet tenemos configurado el español de España y el portugués de Portugal como Spanish y Portuguese, a secas, así que así quedará en los presupuestos. PSI lo sabe, no hay problema.

• El proceso implicará a un solo colaborador*, que adaptará y revisará de manera simultánea. También si el original tiene cambios marcados (no es necesario hacer T+R de los TC). Asegurémonos de explicar a nuestros lingüistas lo que necesitamos en cada encargo de adaptación: adaptar, revisar, no solo centrarse en los TC si los hay, indicar que hay que ser fieles al original si encuentra diferentes unidades de medida… etc.

* Salvo en el caso de traducción + revisión, que un traductor realizará la traducción, otro nativo en la variante inicial la revisará y otro nativo en la variante final la adaptará.

• Como las revisiones, no habrá que marcar las modificaciones con TC; el cliente solo lo necesita en limpio, a menos que digan lo contrario en cualquier proyecto puntual.
• Puesto que lo habitual es que exista un original, seguiremos las normas habituales en lo que concierne a cómo nombrar el archivo adaptado (como el original, acabado en código de idioma de destino), y también para el certificado, si lo piden. Cuando no haya original, consultaremos con el cliente cómo proceder.
• Siempre se añadirá PSI-footer en los documentos adaptados, salvo que digan lo contrario en algún proyecto puntual. Se seguirán todas las normas habituales relativas al pie de página, aunque la línea con información sobre la adaptación seguirá la siguiente estructura:

Translation from English to Spanish (Argentina) dated…

No se hará referencia a “adaptación” sino a “traducción”, del idioma original inglés a la variante de destino.

• Se hará siempre el certificado específico para adaptaciones. Si puntualmente solicitan certificado de traducción para algún proyecto de adaptación que contase con un original, podemos emitirlo, dado que hemos revisado el documento entero contra el original.

Proyectos que implican tailandés

En general, los proyectos que implican tailandés se siguen rigiendo por el resto de procesos acordados con PSI para cada tipo de proyecto. De manera adicional, se tendrán que tener en cuenta algunas directrices específicas dependiendo de si es a/desde tailandés.

Ambas combinaciones

NOTA: En primer lugar, antes de trabajar con tailandés es absolutamente imprescindible instalar el paquete de idioma en Word.

Pie de página

De manera habitual, en la línea del PSI-footer de la descripción del tipo de archivo, no hay que añadir información sobre los sites (centros de estudio) ni el nombre del investigador, que a menudo aparecen en el filename del documento. En el caso de traducciones desde y a thai, sí quieren que incluyamos en el footer todas las informaciones que aparezcan en el filename del documento.

Control de calidad

En las traducciones desde cero que entregamos, en ocasiones el cliente ha encontrado texto oculto (que para nosotros no resultaba visible a simple vista). En adelante, realizaremos los siguientes pasos en todos los proyectos durante nuestro control de calidad:

1. Con el documento abierto, Seleccionar > Seleccionar todo y, con todo el texto seleccionado, ir al menú Fuente y desmarcar Oculto. En ocasiones la casilla sale rellena con un cuadrado. Hagamos clic dos veces (se marca y se desmarca, quedando la casilla vacía). A continuación, hacer lo mismo en footers y en headers.
2. Haremos una búsqueda para confirmar que efectivamente no hay texto oculto:

Buscar > Búsqueda avanzada > Formato > Fuente > Oculto

(para buscar, marcamos la casilla de Oculto). No deberían salir resultados.

Tailandés a inglés (TH>EN)

Documentos editables: pasamos directamente al apartado de “Presupuesto”.

Documentos no editables: Abbyy no siempre reconoce bien los documentos, así qeu hay que revisarlos bien. Si no salen correctamente editados:

• Si tienes la versión Abbyy 8, tendrás que actualizarlo a la versión Abbyy 12 para que pueda leer este idioma.
• Nos aseguramos de que hayamos seleccionado “tailandés”:

• • Si sigue sin salir bien:
    • Le consultaremos al proveedor que editará el PDF (habitualmente, TPL, perfil 822 en nuestro sistema de gestión), cuántos caracteres aproximados tienen los documentos y en qué plazo podría tener los editables listos.
    • Al cliente le explicamos que no podemos procesar correctamente los archivos, por lo que primero debemos realizar el paso de “File preparation” para pasarles el presupuesto exacto. Le informamos sobre el volumen aproximado de caracteres totales (X [el recuento que nos dio el proveedor]-Y [algunas palabras más para cubrirnos las espaldas]) y el plazo en el que tendríamos el presupuesto listo (que sería lo que tarde el proveedor en editar los archivos).
    • Si nos confirma que podemos comenzar con el File preparation, creamos un presupuesto sin recuentos poder crear el job de PRE para enviárselo al proveedor. Cuando tengamos los editables, actualizaremos ese mismo presupuesto con los recuentos finales y se lo enviaremos al cliente. IMPORTANTE: En esta situación es absolutamente necesario estar pendientes de la aprobación del presupuesto por parte del cliente. En caso de que esta no se produzca, habrá que tratar internamente cómo se factura ese trabajo ya realizado.

Presupuesto

A diferencia de otros idiomas, para el tailandés tendremos en cuenta los caracteres. Para calcular el equivalente en palabras para el cliente, simplemente tendremos que dividir el total de caracteres entre 4. Para facilitar el proceso y evitar errores en el cálculo, se aplica esta conversión automáticamente al cargar el report con la pricelist específica de thai en Plunet. Si no, también nos podemos ayudar con la calculadora tailandés de la Okopedia.

Otra peculiaridad es que no aplicaremos fuzzies de ningún tipo ni al cliente ni al proveedor. Así que todas las palabras serán nuevas, excepto las repeticiones, que se cobrarán a la mitad de la tarifa.

Para poder analizar bien los archivos, ya que Trados no segmenta correctamente este idioma, tendremos que configurar los SDLXLIFFs con la combinación de EN>TH. La TM que debemos usar es: en_fake-th_fake.

Ver toda la sección de «Observaciones» al respecto en el artículo Particularidades idiomas (Tailandés).

Proceso

Una vez el cliente confirme, pasaremos el presupuesto a pedido y crearemos los jobs necesarios para TPL:

Tienen que ser específicamente alguno de los que aparecen arriba, ya que están configurados específicamente para estos trabajos.

Como ya hemos explicado anteriormente, los SDLXLIFFs tienen que estar configurados con la combinación EN>TH para que la segmentación sea correcta y usaremos la TM en_fake-th_fake. Para hacer la conversión de caracteres para el proveedor, dividiremos esta vez entre 5. Igualmente, no se contabilizará ningún fuzzy: solo las repeticiones. El recuento al proveedor habrá que añadirlo manualmente. Nos podremos ayudar con la calculadora tailandés de la Okopedia. Tendremos que marcar la opción “Proveedor” y debemos realizar la conversión por separado para las palabras nuevas y para las repeticiones.

Es importante no olvidarnos de avisar a los proveedores de que:

1. Los SDLXLIFFs están configurados con la combinación EN>TH, pero que la traducción es hacia inglés.
2. Si los documentos originales son PDF, el revisor debe hacer una última revisión visual contra el PDF original para asegurarse de que no contenga errores fruto de fallos en el proceso de la edición. Es especialmente relevante en el caso de número y fechas. Debemos reconfirmarlo siempre con el proveedor, haciendo especial hincapié con las fechas.

NOTA: Si en algún momento los revisores solicitan una retribución adicional por realizar este proceso, avisa a un supervisor para que se pueda valorar traspasarlo al cliente.

Actualización de la TM

Tras realizar nuestro control de calidad:

• Subiremos los SDLXLIFFs a la carpeta aa-ToUpdate\medical\PSI-CRO\EN_FAKE-TH_FAKE.
  Para nombrar los SDLXLIFFs, añadiremos los códigos de idiomas “en_fake-th_fake”.
• Modificaremos los idiomas de los SDLXLIFFs por los reales:
  source-language=»th-TH»; target-language=»en-US»
  (ver «Cómo cambiar manualmente el idioma de destino en un sdlxliff«)

y los subiremos también a la carpeta aa-ToUpdate\medical\PSI-CRO.

Trabajos de track changes

Todas las directrices de PSI relativas a trabajos de track changes aplican también para traducciones TH>EN. La única diferencia específica para esta combinación es cómo realizar los cálculos.

En el análisis de Transtools+ nos fijaremos en la columna de caracteres sin espacios.

• Presupuesto: Dividiremos el número de caracteres añadidos/movidos y los eliminados entre 4. Ese será el volumen de palabras con el que se realizarán los cálculos de tiempo habituales.
• Encargo al proveedor: Dividiremos el número de caracteres añadidos/movidos entre 5 y con ese volumen de palabras se realizarán los cálculos de tiempo habituales.

Recordatorio: si es TPL (perfil 822 en nuestro sistema de gestión) quien se ocupe de ambas fases de traducción y revisión de TC, el tiempo para el job debe ser la suma de ambas fases.

Para realizar los cálculos, nos podemos ayudar de la calculadora tailandés en la Okopedia. Si elegimos la opción “Tiempo de TC” nos hará la conversión directa de caracteres añadidos/eliminados a las horas de trabajo necesarias tanto para el cliente como para el proveedor.

Back-translations

Si la traducción TH>EN que solicita el cliente se trata de una back-translation, aplican los mismos procesos que se describen arriba.

Solamente tendremos que considerar que, si se trata de una traducción desde cero, habrá que confirmar o consultar con el cliente si en la forward translation EN>TH se hicieron ajustes de tipografía y formato (ver explicación de inglés a tailandés). Si se hicieron, se le explicará que al traducir el documento en tailandés, la back-translation tendrá todos los ajustes de formato exactos que tenga el texto en tailandés. También habrá que saber si en la back-translation a inglés necesitan que cambiemos de nuevo la tipografía y a cuál, o incluso si necesitan algún ajuste adicional de formato.

Consejo práctico: Si en algún momento necesitamos consultar el recuento de caracteres en un Word, hay que hacer clic en la información de palabras de la parte inferior izquierda de Word. Se abrirá una ventana con toda la información y nos fijaremos en caracteres sin espacios.

Inglés a tailandés (EN>TH)

En proyectos EN>TH aplican todas las directrices de PSI habituales para cada tipo de proyecto. Además, en trabajos de traducción desde cero (en Trados), NO a trabajos de track changes ni proyectos de revisión, aplican las siguientes indicaciones específicas:

Encabezado y pie de página

El encabezado no se traduce, debe permanecer en inglés.

El pie de página será el específico de PSI en inglés, sin traducir. También la paginación. Texto adicional, como por ejemplo “Confidential” sí que debe ser traducido a Thai.

Ajustes específicos de formato

De manera habitual, en traducciones a cualquier idioma, procuramos que la distribución del texto traducido quede lo más equivalente posible a como aparece en el documento original: que ocupe los mismos espacios, que la disposición sea similar, etc.

En traducciones a tailandés haremos lo mismo pero, además de eso, es un idioma para el que nos han pedido algunos ajustes adicionales, que más adelante se especifican.

Presupuesto

Trataremos el documento como si se tratase de un PDF, tanto para calcular plazo, como costes al cliente, como proceso posterior para preparación del archivo.
Es decir, aunque el documento a traducir sea editable, cobraremos la edición del documento como si se tratase de un pdf, por lo que incluiremos una partida de Word(s) File Preparation por el total de palabras. También deberemos tener en cuenta el plazo necesario para realizar la preparación del archivo. En resumen, exactamente igual que si se tratase de un PDF, en todos los sentidos.

Proceso previo a la traducción

En primer lugar, para trabajar correctamente con tailandés, tendremos que haber descargado de antemano el paquete de Word de tailandés. También hay que descargar el paquete de chino (simplificado), puesto que instala cierta configuración de párrafo que puede ser relevante para tailandés.

Borraremos todo el formato del documento y se lo daremos de nuevo manualmente, maquetándolo desde cero. Lo haremos copiando y pegando todo el texto (recuerda copiar y pegar también los encabezados y pies de página, si los hay) en Notepad++ y después copiando y pegando dicho texto sin formato en un documento de Word nuevo. Le daremos el formato maquetándolo desde cero como si de un OCR se tratase, es decir, márgenes, interlineados, negritas, cursivas, tipos y tamaños de letra, etc. Del mismo modo que haríamos con cualquier PDF, si se trata de un documento pequeñito donde tardamos menos en hacerlo nosotras directamente que en externalizarlo, lo podemos hacer nosotras mismas, y si es un documento mayor, podemos externalizar el proceso (Format ya nos ha indicado que puede encargarse con la misma tarifa que cuando le pasamos documentos en pdf. Le tendremos que pasar el documento original e indicarle que necesitamos que le quite todo el formato y lo maquete de nuevo según el primer punto de la Style guide for translations into Thai puesto que vamos a traducirlo a tailandés. También le avisaremos de que se lo enviaremos de vuelta cuando lo tengamos traducido para que lo acabe de ajustar según las especificaciones del cliente para traducciones a tailandés en cuanto a formato se refiere (segundo paso de dicha guía). Podemos decirle lo siguiente: We need you to prepare the file for its translation into Thai. Could you please, delete the format and mimic the source again manually so we don’t find problems while working on it? Once we translate it, we will send it to you again, so you can give it the final format according to the client specifications. Everything is explained in the Style guide for translations into Thai.

Continuaremos el proceso de traducción como normalmente (análisis en Trados, creación de sdlxliff, envío a los traductores, etc.)

Proceso posterior a la traducción

Una vez el trabajo ha sido entregado por los traductores correspondientes, realizaremos el QA habitual, utilizando Xbench, la termbase correspondiente, la guía de estilo de PSI, etc. Si hubiera que hacer cambios, siempre se harán sobre el sdlxliff.

Una vez todo el proceso se ha finalizado, extraeremos el archivo target a partir de dicho sdlxliff. Abriremos los archivos target y comprobaremos que las negritas/cursivas/subrayados/superíndices del original se han traspasado correctamente al target. Si no fuera el caso, habría que arreglarlo dentro del sdlxliff y volver a exportarlo de nuevo.

En cualquier caso, el archivo exportado del sdlxliff debe enviarse tal cual a Format para que acabe de hacer los ajustes de formato correspondientes. Este paso con Format no tiene coste adicional y está incluido en su coste inicial de preparación de archivos.

Formato de entrega de traducciones en thai

IMPORTANTE: Se ha detectado que los cambios realizados con Office 365 no se visualizan correctamente como el cliente espera. En cambio, con Office 2016 parece ser que sí. Por ese motivo, los target exportados del sdlxliff no deben modificarse por nosotras, sino enviarse tal cual a Format. Del mismo modo, será Format quien haga los siguientes ajustes de formato y nosotros no modificaremos nada de lo que nos entreguen (simplemente comprobar que está correcto).

Igual que con el resto de traducciones, debemos respetar el formato original, con las siguientes particularidades:

• Cambiar el tipo de letra a TH Sarabun PSK. Es la que usaremos por defecto pero, si por cualquier motivo hubiera que usar otra, podremos usar alguna de estas otras.
• Antes de realizar ningún ajuste adicional, valorar el tamaño de la letra. Es probable que la tipografía anterior y la nueva no tengan un tamaño similar. Hay que modificar el tamaño de la letra de modo que quede equivalente al original visualmente. Por ejemplo, si el texto original está en Arial 11, en tailandés equivaldría a TH Sarabun PSK 15.

Revisar los tamaños a lo largo de todo el documento, por si hay apartados enteros o tipos de frases (por ejemplo, los distintos niveles de títulos) en diferentes tamaños. Habrá que ajustarlo a mano, pero podemos ayudarnos de la función de copiar formato de un texto a otro o modificar los ajustes por Estilos.

• A los textos cuya alineación de párrafo sea justificada, modificarles dicha alineación de párrafo a “Tailandés distribuido”.

Asegurarse de que no haya líneas cuyas letras tienen una separación entre ellas fuera de lo estándar (a priori este problema solamente se da con Office 365, pero conviene abrir lo que entregue el último recurso previo a nuestra entrega para asegurarse antes de cualquier entrega al cliente).

• Sin conocer el idioma, no podremos hacer muchos más ajustes que los descritos. Sin embargo, al cambiar la tipografía o/y los tamaños de letra, es probable que los textos ocupen espacios diferentes a los iniciales, así que si detectamos algo que a simple vista no tiene la misma distribución que en el original, se puede “jugar” con las sangrías para forzar la distribución que buscamos.

• Tras la entrega de Format, solicitaremos a quien se haya encargado de la traducción o de la revisión (el que prefiramos) que eche un vistazo al archivo que pretendemos entregar al cliente por si detecta algo no correcto en tailandés (por ejemplo, problemas con los tonos a final de línea, u otras necesidades que indique PSI y que formen parte del propio idioma). Le pediremos que nos pase el documento en pdf para estar seguros de que el cliente ve el documento también con el formato correcto. Podemos decirle lo siguiente: Please, check the Thai files and make the changes needed so everything is ok in terms of formatting and readability due to the lack of punctuation marks, tone marks, etc. Could you please, also send us the final document in PDF?

Al cliente le entregaremos tanto el word como el pdf indicáncole que en nuestro word lo vemos todo bien pero que se lo pasamos también en pdf para asegurarnos de qué él también lo ve bien no vaya a ser que por utilizar una versión de Word distinta a la nuestra no sea así.

Si después de una entrega, el cliente comparte alguna indicación adicional que no sea específica para ese proyecto sino extrapolable al proceso general de ajuste de formato, informa a tu coordinadora para incluir las nuevas directrices en el procedimiento.

¡IMPORTANTE! Si después de la traducción a tailandés el cliente solicita una back-translation, ver el apartado Back-translations en la explicación anterior.

Explicaciones adicionales sobre tipos de letra

There is not requirement from EC or regulatory authorities regarding what font should be used, but EC requires fonts that Thai people can read. Font should be readable, legible, normal, familiar, etc. The 14 Thai fonts that Thai Secretariat of The Cabinet encourages to use are listed below:

1. TH Sarabun PSK (most recommended)
2. TH Chamornman
3. TH Krub
4. TH Srisakdi
5. TH Niramit AS
6. TH Charm of AU
7. TH Kodchasan
8. TH K2D July8
9. TH Mali Grade 6
10. TH Chakra Petch
11. TH Bai Jamjuree CP
12. TH KoHo
13. TH Fah Kwang
14. TH Chulabhorn Likhit

Trabajos de track changes

Las indicaciones anteriores para EN>TH no aplican a trabajos de track changes. Estos trabajos se rigen por las directrices generales de PSI para proyectos de TC y las siguientes consideraciones.

El pie de página dependerá de cómo se haya procedido en la traducción que hay que actualizar. Si en el original hay TC, se implementarán en la traducción traducidos o sin traducir, dependiendo de cómo salga el resto del pie de página. Si en la traducción no hay pie de página y en el original se ha añadido, lo añadiremos en la traducción en inglés (sin traducir).

El proceso previo a la traducción para proyectos a tailandés no aplica en proyectos de track changes. El traductor implementará sus TC siguiendo el mismo tipo de letra/formato presente en el documento. Al asignar los trabajos le pediremos al traductor y revisor que se aseguren de que las palabras añadidas con TC queden con una segmentación correcta en tailandés, ej. sin palabras separadas en dos líneas por donde no procede. La revisión de formato del documento entero habitual en los proyectos de TC aplica también en proyectos a tailandés. Únicamente en este idioma, se presupuestará incluso aunque sea inferior a media hora de trabajo (añadiremos media hora). Lo calcularemos en base a 3,5 minutos/página del documento original con track changes (en lugar de 2 minutos, como en el resto de idiomas) porque, además de nuestra revisión de formato habitual (a realizar por la PM), también necesitan que revisemos la segmentación de todo el texto, las marcas de tonos, etc., para garantizar que sigan siendo correctos tras la actualización del documento (a realizar por un nativo). Añadiremos un ítem de Hours file preparation y le informaremos al cliente que corresponde a la revisión de formato del documento entero.

Para resumir, los pasos a seguir son:

• TRA -> REV -> VER + revisión de formato del documento entero por parte de la gestora à Revisión de formato del documento entero por parte del revisor
• Al enviarle de nuevo el documento al revisor para revisar el formato del documento entero, le preguntaremos qué versión de Word utiliza y le pediremos que nos envíe el documento actualizado también en formato PDF. Le podemos dar las siguientes instrucciones sobre la revision de formato: Please, check all the text (not only the TC parts) and make any changes needed so everything is correct in terms of formatting and readability due to the lack of punctuation marks, tone marks, etc. Could you please, also let us know your Word version and send us the final document in PDF?
• Al cliente le entregaremos tanto el Word con TC como el PDF, explicándole que así es como lo vemos nosotros pero que se lo pasamos también en PDF para asegurarnos de que ellos también lo vean igual, no vaya a ser que por utilizar una versión de Word distinta a la nuestra no sea así.

Documentos para EE. UU.

Los trataremos como cualquier otro tipo de documento salvo por las siguientes excepciones:

Cómo identificar si son documentos para EE. UU.

• Todos los proyectos que involucran ES-US (sea traducción a ES-US o desde ES-US/back-translation).
• El 99% de dichos proyectos son documentos dirigidos a pacientes, es decir, Informed Consent Forms (ICFs), patient cards, etc.,
• Los archivos harán alguna mención a USA en el filename, el footer o el header.
• EE. UU. sigue unas convenciones algo diferentes al resto de la documentación que recibimos por parte de PSI, como por ejemplo, que el filename del archivo no siempre contiene información de ese documento en particular sino del template general que se ha usado para elaborarlo, y la fecha que consta en el filename no tiene por qué la fecha del documento, sino la de aprobación del documento por parte del Institutional Review Board (IRB, equivalente al comité de ética en EE.UU.).

Presupuesto

En proyectos de track changes, es frecuente que envíen los originales en dos versiones: con TC y clean. Para el presupuesto, registraremos en Plunet el nombre del documento clean.

Footer

• Las indicaciones generales sobre el PSI-footer para documentos dirigidos a pacientes no aplican en el caso de aquellos para EE.UU.
• No hay que añadir el PSI-footer. Tan solo traduciremos el header/footer ya presente en el documento, sin modificarlo.

Filename del archivo actualizado

Como excepción, en documentos para EE. UU. no se añadirá “redline” al final del nombre del archivo actualizado.

Certificado

• Tipo de certificado en proyectos de TC: En los proyectos de track changes, los Institutional Review Boards (IRBs) de EE.UU. no aceptan certificación parcial, así que en todo proyecto de TC emitiremos full CoT. PSI se ha comprometido a realizar solo TC estándar (actualización de un mismo documento, de una versión a otra posterior), no reutilizar documentos similares (de diferentes sites). Al tratarse de TC estándar, podemos emitir el full CoT con seguridad porque hemos traducido y revisado todo el contenido, tanto la base, en el proyecto inicial, como las sucesivas actualizaciones estándar. Si se trata de un proyecto de TC no estándar o el documento ha pasado por TC no estándar anteriormente sin hacer full revision, les explicaremos que tenemos que hacerla para poder emitir el CoT.
• Fecha del documento: Es habitual que estos documentos cuenten con varios tipos de fechas diferentes en header/footer. Las más habituales son: fecha de aprobación del IRB, fecha de la versión global/maestra, fecha de revisión (Revised…), etc. Si en algún documento aparece una fecha que indica claramente que es de la versión USA, esa es la fecha de la versión local, que es la que incluiremos en el campo Document date del certificado de traducción. En caso de que no se explicite una fecha de la versión local, será el cliente quien nos deberá aclarar cuál es la fecha de documento que necesitan. Si se trata de una back-translation, la fecha de Document Date será la fecha de traducción de la forward translation.
• Fecha de la traducción: para el campo Translation date, pondremos la fecha den que entregamos la traducción (la inicial, no tras la revisión del cliente).

Protocolos, Manuales de Investigador y Expedientes de medicamento en investigación

Entre los proyectos más voluminosos que realizamos para PSI se encuentra la traducción de protocolos, manuales de investigador (Investigator’s Brochures, IBs) y expedientes de medicamento en investigación (Investigational Medicinal Product Dossiers, IMPDs).

Estos tipos de documentos presentan algunas características que se explican en detalle aquí.

Summary of Changes (SoC)

La explicación de qué es un Summary of Changes (SoC) y todo lo relativo al presupuesto, traducción y control de calidad se detalla en el curso en Okodemy “Cómo gestionar un Summary of Changes (SoC)”.

Al asignar la traducción/revisión, debemos enviar a los lingüistas el enlace que encontrarán en la Translator’s Knowledge Base remarcando que es muy importante que lean las indicaciones sobre cómo trabajar con un SoC y cómo actuar en caso de encontrar diferencias de contenido entre el SoC y el documento de referencia.

Anexos económicos en Excel

Son documentos Excel para los que, en ocasiones, nos piden recibir la traducción en formato bilingüe. Aunque en el documento original haya celdas que indiquen «[Insert Translation]» o “[Translation]”, preguntar en cada solicitud si necesitan la traducción en formato bilingüe o no, porque en muchos casos no es así.

1. Si solo quieren la traducción en idioma de destino, bloquearemos esas palabras sueltas en Trados y se pueden entregar sin traducir.
2. En casos puntuales piden 2 versiones del Excel, una solo en idioma de destino y otra bilingüe. Para el presupuesto, se procederá como se indica en el apartado 3. Presupuestamos el tiempo de preparación del bilingüe, pero añadiremos dentro de ese cálculo 1 hora adicional. El proceso será el mismo que se explica en el apartado 3. Se preparará el bilingüe y se enviará a traducir de ese modo. Cuando recibimos la traducción, ya tenemos la versión del Excel bilingüe y “obtendremos” la versión en idioma de destino de manera interna. Crearemos una TM donde importaremos el SDLXLIFF de la traducción que hemos recibido y pretraduciremos el Excel original (sin preparar bilingüe) (opción 2 de este artículo). Tendremos que revisar con atención el target exportado porque es habitual que haya que retocar formatos (negritas, subrayados, etc.).
3. Si solo quieren la traducción bilingüe, habrá que preparar el archivo de ese modo antes de enviarlo a traducir (no es necesario hacerlo para el presupuesto). El proceso para la traducción bilingüe es el que se explica a continuación.

Presupuesto

En el presupuesto añadiremos una partida de Hour(s) File preparation, que calcularemos en base a 20 segundos por celda. Para un cálculo más automático, podemos usar la calculadora específica para esto disponible en el CRM.

Esta partida se redondeará para el cliente, de 15 en 15 minutos (en lugar de media hora como de costumbre), y es que sería excesivo un redondeo superior por unas pocas celdas.

Podemos consultar en el Excel el número de celdas (celdas con contenido) que hay en el documento:

Se selecciona la hoja entera haciendo clic en el recuadro de arriba a la izquierda y el dato se muestra abajo en Recuento.

¡OJO! Tendremos que mirar el dato en una copia del Excel donde vaciemos/borremos las celdas que no se han de preparar bilingües, es decir, en el ejemplo de la captura se deberían haber borrado todas las celdas que contienen solamente números.

¡OJO! Hay que mirarlo en cada hoja del Excel por separado.

Preparación

Se prepara el documento original antes de enviarlo a traducir. Para evitar hacerlo de manera manual, se han desarrollado unas macros que realizan la preparación de manera automática y un filtro para Trados para analizar correctamente el archivo Excel bilingüe.

Encontraremos las macros y el filtro en el CRM > Okopedia > Página de descargas, y la explicación del proceso de preparación completo aquí.

IMPORTANTE

Tras la preparación del Excel con las macros, tendremos que revisarlo de manera pormenorizada, debido a las limitaciones de las macros.

Además, como se indica en la guía de preparación, no olvidemos informar al cliente en la entrega si quedó alguna fórmula que no servirá en adelante.

Clinical Trial Agreements

Un Clinical Trial Agreement (CTA) o Clinical Study Agreement (CSA) es un contrato que recoge diferentes condiciones legales relativas al desarrollo del estudio clínico, a menudo entre el promotor y un centro de estudio. Será fácil identificar este tipo de contratos por su contenido legal y la distribución del texto en cláusulas, seguido de un apartado de firmas al final y posibles anexos adicionales. Solemos recibirlos en formato Word. En estos documentos no añadiremos PSI-footer. Sí traduciremos/revisaremos el footer/header que pueda traer el documento.

Traducción de CTA

Cuando traducimos desde cero un CTA, tenemos la misma libertad a la hora de traducir que con cualquier tipo de proyecto y el revisor podrá realizar todas las correcciones que vea necesarias sobre la traducción (no como en los encargos de revisión de CTA).

El principal requisito de PSI en traducción de CTA y de cualquier tipo de contrato es calcar el uso de mayúsculas del original, en lugar de seguir las convenciones habituales del idioma de destino, por ejemplo, en términos como Sponsor, Hospital, Clinical Trial, Protocol, Agreement…

Una vez la traducción se le envía al cliente, la revisan internamente y queda validada en adelante. No podrán realizarse cambios si se reutiliza dicha traducción en el futuro, por lo que es muy importante finalizar estas traducciones con la mejor calidad posible.

En ocasiones piden recibir este tipo de traducciones en formato bilingüe, a doble columna, texto original a la izquierda y texto traducido a la derecha, y tendremos que preparar el archivo de manera interna. Consultar apartado «Preparaciones especiales de archivos editables».

Es frecuente que este tipo de documentos contengan comentarios, procedentes de PSI o del departamento legal. Consultar apartado «Documentos originales con comentarios del cliente». También tendremos que presentar de manera bilingüe el texto de headers y footers y los elementos que no formen parte de una tabla en el documento original, por ejemplo, las firmas. Estos elementos los prepararemos, frase a frase, separando original y traducción con una barra vertical como separador.

Trabajos de track changes

Algunos de los CTA que traducimos son en realidad plantillas de contrato, y es por eso que enfatizan que una vez traducido ya no se pueden realizar cambios, salvo los que surjan en el proceso de usar esas plantillas para elaborar nuevos contratos. En estos casos, recibiremos el documento con cambios marcados, para actualizar las traducciones existentes.

Nos han pedido que siempre que recibamos un proyecto de actualización con TC se ocupe de ello el mismo equipo de traducción que tradujo la versión anterior (de no ser posible, hay que avisarles. Valorarán si prefieren esperar a que el equipo esté disponible o continuar con otros traductores). Pidamos al cliente que nos dé la referencia del proyecto inicial, para poder identificar al equipo de traducción (si no se logra, otro equipo).

En estos proyectos de TC sobre CTA es muy importante no emitir certificados de traducción estándar, sino aquellos que especifican que solo hemos traducido los cambios marcados. En su momento nos explicaron que, por la naturaleza de estos textos y su finalidad, puede ser que los contratos sufran modificaciones realizadas internamente por el equipo legal, es decir, ni realizadas por Okodia ni consultadas con Okodia. Será contenido que constará ya en los documentos, sin marcar y no podremos distinguir, unido al hecho de que es muy frecuente que las plantillas de CTA se reutilicen mucho y perdamos el rastro con mayor facilidad. Certifiquemos siempre que solo hemos trabajado en los TC. (Si el cliente insiste en recibir full CoT, avisa a tu coordinadora).

Revisión de CTA

En ocasiones nos piden realizar la revisión de un contrato traducido y su original. Pueden enviarlos en dos archivos separados o en uno solo, bilingüe, dispuesto a doble columna.

La finalidad de estas revisiones es únicamente corregir errores o diferencias de contenido/significado. El texto previo del CTA se considera validado, por lo que no podremos realizar cambios preferenciales. Derivemos al revisor a la PSI style guide, donde se explica esto. Cualquier sugerencia adicional, por ejemplo, relacionada con inconsistencia en terminología o términos con los que el revisor no esté de acuerdo del todo, se le puede comentar al cliente añadiendo un comentario, pero nunca realizando cambios directamente en el texto.

Para el presupuesto, se ha establecido una excepción respecto al procedimiento general de proyectos de revisión. Se estimarán 750 palabras/hora, que se calculará sobre el recuento de palabras del idioma original. En los CTA que nos piden revisar es frecuente que el original contenga información que habrá que cambiar o incluso rellenar en la traducción, es decir, habrá que traducir todas las diferencias de contenido que se encuentren para hacer que la traducción coincida por completo con el original. Como la revisión será menos productiva cuantos más cambios haya que implementar, la ratio para CTA lo compensa. También podemos usar esta ratio para revisiones no estándar (de otros tipos de documentos) en las que también se esperen más diferencias de contenido de las habituales en un proceso de revisión habitual.

IMPORTANTE: antes de preparar el presupuesto debemos mirar bien el contenido de original-traducción, de principio a fin. Si, más allá de las diferencias esperables en estos proyectos, encontramos en el original algún extracto, entero, de longitud relevante que no consta en la traducción, le explicaremos al cliente que ese apartado se ha presupuestado para su traducción (T+R como siempre), no revisión. El resto del documento se contabiliza para revisión con la ratio para CTA.

Policy Endorsements

Entre los documentos que traducimos para PSI encontraremos distintos tipos de pólizas o certificados de seguros que, a menudo, son similares entre sí o similares a proyectos anteriores. Este apartado se ha diseñado únicamente para los policy endorsements que veremos en la imagen a continuación.

Estructura y características principales

El cliente llama policy endorsement o similar (en los asuntos de los emails/en los nombres de los archivos) a pólizas de seguros de responsabilidad civil, emitidas siempre por la misma empresa (HDI Seguros) y que siempre tienen la misma estructura y un contenido muy muy similar. Son documentos PDF en español que traducimos a inglés.

No haremos el proceso de PRE+TRA+RVW habitual sino revisión, usando una traducción anterior (como plantilla, digamos), que revisaremos y modificaremos como sea conveniente para hacer que coincida 100% con el nuevo documento que nos piden traducir.

La estructura habitual del documento es la siguiente:

• Pág. 1: la portada es siempre igual pero los datos que aparecen al principio pueden cambiar entre documentos.
• Pág. 2-5: condiciones particulares del seguro. Casi siempre los elementos que cambian son números nada más, pero aún así es la parte del documento donde más cambios se concentran, así que será mejor que lo mire un revisor.
• Pág. 6 en adelante: condiciones generales de los seguros que al 99% serán siempre iguales. Lo habitual es que solamente cambie el número de póliza que aparece en el encabezado.

Al recibir un policy endorsement, normalmente el cliente ya nos envía también una traducción anterior similar con su original, o nos menciona un proyecto anterior que tradujimos y podríamos buscar el original en Plunet. Si no envían ni hacen referencia a nada anterior, usaremos los archivos del proyecto de referencia O-22660 (ver más instrucciones en la sección “Presupuesto” de este apartado).

Como primer paso, siempre comprobaremos la similitud del nuevo documento que hay que traducir con el anterior, para confirmar que efectivamente tiene sentido gestionarlo de este modo. Comparamos los dos originales en PDF en Draftable, pero esto nunca se lo diremos al cliente. No queremos sentar precedente. Sí se les puede decir que hemos visto que el documento para traducir es muy similar a otros anteriores/al que envían, pero no entraremos en detalles de cómo lo hemos visto, ya que en teoría “no podemos” comparar documentos no editables (documentos Word ya saben que sí).

Si los cambios que habría que hacer en la traducción previa son los pocos que hemos descrito más arriba, se procederá como explicaremos a continuación.

Evidentemente, si cualquier día envían uno que difiera mucho más de lo descrito, será más razonable hacer el proceso habitual de PRE+TRA+RVW. En ese caso, habrá que pedirle a nuestro proveedor de edición que el formato del editable sea lo más parecido posible al de O-22660.

Presupuesto

Normalmente, el cliente solicita la traducción de este documento enviando también una traducción anterior (como referencia, para usar, para revisar… pueden decirlo de muchas formas) o incluso el original de ese proyecto anterior. Comprobaremos la similitud de los documentos para confirmar que podemos proceder de este modo. Les diremos que hemos comprobado que el documento que envían es muy similar (sin detalles) y que podemos hacer lo siguiente: mantener exactamente iguales (sin revisarlas) las páginas 6 en adelante, porque todo parece ser idéntico*, y solo cambiaremos el código del encabezado. Y, para las páginas 1-5, revisaremos la traducción anterior y haremos los cambios necesarios para que el contenido coincida al 100% con el documento que necesitan traducir ahora.

* Nota: Suena incierto porque daremos a entender que lo hemos mirado a ojo, pero ya lo habremos confirmado en Draftable.

Se presupuestan 2,5 horas de revisión. (Quote de referencia: Q-18056-01)

¡OJO! No es esperable que ocurra pero, si el cliente tiene dudas de hacerlo así, le ofreceremos revisión de la traducción entera contra el original.

¿Y si no envían ninguna traducción previa para usar y solo piden traducción (sin más detalles ni mención de similitud con encargos anteriores) de un policy endorsement?

Si envían para traducir un documento y la PM lo identifica como un policy endorsement, no aparentaremos no darnos cuenta. En la medida en que identifiquemos que se trata de este tipo de documento, lo primero que haremos será acudir a esta Order de referencia, O-22660, y descargar el PDF original y la traducción que entregamos. Comprobamos la similitud de los dos documentos originales con Draftable y procedemos como hemos explicado. Le diremos al cliente que conocemos ese tipo de documento, que suelen ser todos muy similares y que podemos hacer como hemos hecho en otras ocasiones, revisar una traducción previa que tenemos en nuestro archivo* para hacer que coincida al 100% con el documento que necesitan traducir ahora. Se procede como hemos descrito antes.

* Nota: No se la enviaremos si no la piden.

Proceso externo

Si de la pág. 6 en adelante solo cambia el código del encabezado, lo cambiará la PM.

Al revisor se le envía el original nuevo en PDF y la traducción previa en Word y se le pide que revise solamente las páginas 1-5, ambas incluidas, y que haga los cambios que se requieran para que el contenido sea idéntico al original. Podríamos enfocarlo como un trabajo de track changes como tal, porque tenemos la comparación de Draftable, pero no lo hacemos. Le pedimos que revise entera esa parte. Le explicaremos que esos documentos son siempre muy parecidos, así que solamente debemos realizar cambios de contenido, no preferenciales.

Se le emite una PO por 1 hora de revisión.

Control de calidad y entrega

La PM puede utilizar como referencia la comparación de Draftable, ya que al fin y al cabo muestra los únicos cambios que se deberían hacer en la traducción.

Se guarda y se envía al cliente en versión en limpio, sin cambios marcados. Habrá que enviarlo siguiendo las convenciones habituales de cualquier traducción, es decir, con el footer modificado como se requiera, con los datos específicos de esa póliza y nombrar la traducción conforme al documento original.

Labels

Estos documentos contienen textos para etiquetas para el producto en fase de investigación. Son plantillas que presentan siempre la misma estructura (varias tablas, texto al final, etc.) y en las que no traduciremos todo el contenido. Únicamente se traduce el texto de la etiqueta en sí, el que encontraremos en la tabla principal del documento, en la columna central (habitualmente estará marcada como “Country-specific master”).

Entregaremos el documento con el resto del contenido sin traducir y con la traducción del texto de la etiqueta en la columna destinada para ello (“Into local language translation”). Además, escribiremos en inglés el idioma de destino y la fecha de la traducción (fecha de entrega) en las celdas correspondientes en la tabla de la primera página.

En estos documentos no aplica el PSI-footer.

Campo de idioma: en cursiva, nombre del idioma desarrollado, evitando códigos de idiomas. Ej. Spanish (Mexico)

Campo de fecha: en cursiva, añadiendo “Draft” y siguiendo el formato de fecha que aparece en celdas contiguas. Ejemplo: Draft translation dd. 04-Jul-2024

Structure data fields

Son documentos que nos envían con una estructura bilingüe que habrá que preparar para traducir, copiando el texto para traducir en las celdas destinadas a la traducción y ocultando todo lo que proceda. Como cualquier preparación especial de archivos editables, presupuestaremos el tiempo que conlleve.

Además, son documentos donde aparecen diferentes limitaciones de caracteres. Consultaremos con el cliente si hay que seguir esas limitaciones o no, ya que no siempre lo requieren. En caso de necesitarlo, ver aquí las distintas consideraciones aplicables.

Traducción de archivos InDesign o Illustrator

Consultar el procedimiento general relativo a proyectos de InDesign y maquetación en PM001 – Procedimiento general Gestión de Proyectos. Ver también los cursos de Formación InDesign y Documentos PDF susceptibles de necesitar maquetación (DTP). A continuación los procesos específicos acordados con PSI, diseñados en particular para proyectos de traducción (traducción + revisión) desde cero. Si surge un proyecto de traducción de track changes o cualquier otro proceso diferente a traducción, habla con un supervisor.

NOTA SOBRE ILLUSTRATOR: es muy poco habitual trabajar con archivos Illustrator (extensión .ai). El proceso en general será el que se explica a continuación para InDesign, pero todas las particularidades específicas de Illustrator se detallan en el apartado Archivos Illustrator.

Características de los proyectos

Los archivos InDesign son bastante pesados y a menudo no se pueden enviar por e-mail. Si el cliente nos consulta, le ofreceremos que suban los documentos a nuestro servidor, a la carpeta Drop. Verificar la contraseña en el excel de contraseñas, pestaña Clientes:

You can access through the following link (https://sharepoint.okodia.com/owncloud) with the following credentials:

Username: xxx

Password: xxx

Whenever this folder is used, we would need you to inform us that you uploaded files to the Drop folder.

IMPORTANTE: Puesto que esta carpeta es común para todos los clientes, cada vez que se cuelgue algo en Drop, debemos descargarlo y borrarlo de ahí, para que la carpeta quede libre/vacía para el siguiente uso/cliente.

Sin embargo, quizás optan por subir los documentos a su propio servidor, al que nos han dado acceso. En el excel de contraseñas, pestaña Clientes, tenemos la web y los datos de acceso (PSI Transfer).

Mientras los proyectos con InDesign sean esporádicos, conviene confirmar con el cliente, en cada proyecto, si necesitan:

• Solamente traducción (se sobreentiende T+R, puesto que es PSI): informándoles de que su equipo de DTP debería hacer algunos ajustes en las cajas para que se vea bien el texto, debido a las diferencias en longitud entre los distintos idiomas.
  Solo necesitaríamos el .idml y el PDF, como referencia visual. Si lo envían en .indd, abriéndolo en InDesign podremos guardarlo/exportarlo en .idml. Si encontramos algún problema de compatibilidad, ver apartado Presupuesto > Problemas al analizar los documentos.
• Traducción y posterior maquetación: necesitamos el paquete completo por cada documento que haya que traducir (PDF, .idml, links, fuentes). Ver Proceso.

PSI-FOOTER. Consultemos también en cada proyecto si habrá que añadirlo o no, ya que no hay un procedimiento fijo. Necesitaremos saberlo para incluirlo en la fase de traducción y, definitivamente, para la fase de maquetación.

Si requieren PSI-footer:

• siempre que nos lo indiquen antes de proceder con la maquetación, no implicará ningún coste adicional, está incluido en el coste de DTP por página que reflejaremos en el presupuesto.
• si lo solicitan una vez ya hemos entregado las traducciones maquetadas o si durante la fase de maquetación la inserción del footer requiere más ajustes de los esperables, presupuestaremos los costes asociados (el tiempo de DTP que indique el maquetador).

Presupuesto

Guardaremos en la carpeta source los originales en PDF y en .idml, y si tenemos los paquetes completos, los guardaremos en una carpeta independiente (por ejemplo, en la carpeta ref.) para poder compartirlos con el maquetador.

InDesign es un formato editable, por lo que el presupuesto se preparará analizando los .idml como cualquier otro formato editable. Si también nos encargaremos de la maquetación de la traducción, se añadirá un item de Page(s) DTP con el total de páginas sin importar longitud (lo más eficaz es consultar el total de páginas de los originales PDF). No olvidemos que el propio item de DTP deberá superar la tarifa mínima del cliente o, si no, aplicaremos una tarifa mínima para el item DTP.

NOTA: En ocasiones algunos PDF muestran 2 páginas en 1 página dentro del PDF. En estos casos deben contabilizarse como 2 páginas realmente, ya que dentro de InDesign se ven como 2 páginas realmente.

Es importante especificar dentro del presupuesto los plazos desglosados de cada proceso, para que no haya malentendidos y entiendan que el plazo final dependerá también de su proceso de revisión interna. Por ejemplo:

5 working days for translation and review + 2 working days for DTP

Dentro del presupuesto o en nuestro email, también conviene aclarar que el plazo para DTP comienza a partir de que PSI nos envíe las traducciones revisadas por ellos.

Si habrá que añadir PSI-footer, lo(s) escribiremos en un Word que incluiremos en el recuento del proyecto.

Si hay imágenes en los documentos (con contenido traducible pero que no aparece en InDesign/Trados), necesitaremos ese contenido editable. Si son varias imágenes, podemos preguntar al cliente si nos las podrá enviar editables. Si son una o dos, podemos extraer el contenido nosotras directamente y añadiremos al presupuesto un item de Word(s) File Preparation. Extraemos el texto para traducir en formato tabla a dos columnas, para facilitarle el proceso posterior al maquetador, de forma similar a como se hace con las imágenes que hay dentro de cualquier Protocolo.

Problemas al analizar los documentos

En ocasiones tenemos problemas para abrir el documento en InDesign o para analizarlo en Trados, por cuestiones de compatibilidad de versiones.

Lo importante es que podamos abrirlo en InDesign para hacer las comprobaciones iniciales en el documento para prepararlo para traducir. Si al abrirlo aparece un aviso indicando que el archivo se ha preparado con una versión de InDesign posterior y no nos permite visualizarlo, pediremos al maquetador (sin coste) o al departamento de SM que lo conviertan a una versión anterior.

Incluso con la versión adecuada podría ocurrir que el archivo no sea compatible con Trados, y que, al cargarlo en el proyecto, no lo detecte como “Traducible” sino como “Referencia”. Realizaremos este ajuste en la configuración del proyecto y podremos seguir con el proceso.

Proceso

Traducción, revisión y control de calidad

Seguiremos el proceso de traducción y revisión habitual, con los SDLXLIFFs correspondientes (no olvidemos enviar al traductor/revisor el/los PSI-footer para traducir, si procede).

Cuando tengamos las traducciones, realizaremos nuestro control de calidad habitual con Xbench.

Revisión interna de PSI

Con las traducciones revisadas por nosotros, en Trados, exportaremos cada documento para revisión bilingüe, que será como PSI hará su revisión interna. También quieren dar su OK a los PSI-footers traducidos antes de incluirlos en los archivos maquetados. Estos se los enviaremos directamente en el Word donde están traducidos.

¡IMPORTANTE! Tras exportar para revisión bilingüe, de cada Word haremos una copia, donde borraremos las dos primeras columnas (número y estado del segmento), y así se lo enviaremos al cliente.

Les pediremos que informen a sus revisores de que todo cambio que realicen deben hacerlo con la función de track changes activada y que, si en alguna frase ven etiquetas (números/códigos de colores), no deben modificarlas.

Tras recibir los archivos revisados por parte de PSI y revisar por encima que hayan respetado estas instrucciones, necesitamos volver al formato inicial de 4 columnas para llevarlo a Trados. Pegaremos las dos columnas revisadas dentro de los Word bilingües originales que exportamos, reemplazando las dos columnas previas a la revisión. Lo haremos con TC desactivado, para que se peguen como necesitamos (que salgan con TC solo las modificaciones).

De vuelta en Trados, volcaremos esos cambios en los SDLXLIFFs (Actualizar desde la revisión bilingüe). Si el cliente siguió las instrucciones, el proceso debería funcionar. Si los cambios no se aplican automáticamente, habla con un supervisor para valorar cómo proceder en función del número de cambios (se avisó a PSI de que podríamos aplicar un coste adicional si realizaban la revisión sin ajustarse a nuestras indicaciones).

NOTA: si los cambios de PSI son muy pocos, será mucho más eficaz implementarlos directamente en el SDLXLIFF de forma manual que realizar este proceso.

Una vez confirmado que el SDLXLIFF se ha actualizado correctamente, aceptaremos todos los cambios, guardaremos el SDLXLIFF final y exportaremos el archivo de destino (.idml), y podemos proceder con la maquetación.

Maquetación

Enviamos al maquetador, por cada documento, el paquete original y el .idml traducido (+ Word con imágenes, si lo hay).

Si hay que insertar footers, le diremos el texto exacto para cada documento y le indicaremos en qué lugar del archivo debe añadirlo. Si en alguna ocasión puntual el maquetador nos avisa de que la inserción de footers lleva más trabajo del habitual, presupuestaremos al cliente el mismo tiempo que nos indique el maquetador (tendremos margen en la diferencia del coste por hora entre uno y otro).

Normalmente nos enviará el paquete final, que será lo que entreguemos al cliente. Abriremos el .idml para confirmar que es el traducido y revisaremos en la versión PDF que todo se haya maquetado correctamente, o si no pediremos al maquetador hacer las correcciones necesarias. Cuando esté todo en orden, realizaremos la entrega al cliente.

Entrega

Los documentos suelen ser muy pesados para entregar por email en el hilo del proyecto así que, de manera puntual en estos proyectos, realizaremos la entrega por Plunet con la opción via download link (e-mail).

Si solo realizamos la traducción, por cada documento, entregaremos al cliente el .idml traducido (+ imágenes en Word, si las hay) y el PDF (sin maquetar), que se puede exportar desde InDesign.

Si también nos ocupamos de la maquetación, enviaremos el paquete entero por cada documento: PDF, .idml, .indd, carpeta de fuentes y carpeta de links.

Modificaciones posteriores a la entrega

Si una vez finalizado el proceso de maquetación el cliente solicita realizar cambios en el documento que no sean fruto de errores nuestros (incluidos cambios en el PSI-footer), consultaremos al maquetador el tiempo que estima necesario y presupuestaremos al cliente el mismo tiempo que nos indique el maquetador (tendremos margen en la diferencia del coste por hora entre uno y otro).

Archivos Illustrator

En general, no podemos trabajar directamente sobre archivos Illustrator (.ai) porque las herramientas de traducción no los consideran editables, así que se tratarán como archivos no editables de cara al proceso de traducción (como si fuera un PDF). Los editaremos a Word para poder traducirlos, por lo que presupuestamos al cliente Word(s) File preparation.

NOTA: si el archivo es de varias páginas, consulta con un supervisor si será mejor editarlo a Word o si interesa adoptar otro enfoque, como volcar el contenido con Sysfilter. (Sysfilter es una herramienta específica que funciona para Illustrators de varias páginas, CorelDraw, etc. Esta herramienta no es gratuita y también debe valorarse la viabilidad de su adquisición).

Consultaremos al cliente si necesita solo la traducción o también la posterior maquetación.

Si necesitan solo traducción, es importante explicarle al cliente que no podemos trabajar directamente sobre .ai, así que recibirán la traducción en formato Word. Eso sí, podemos ofrecerles entregarles la traducción en Word con un formato (colores de fondo, gráficos, etc.) lo más similar posible al original (ese File preparation que requiere una mayor dedicación y por lo tanto se contabiliza por horas. Consultar antes con el maquetador cuánto tiempo estima necesario) o, si no les interesa, haremos una edición convencional.

Si el cliente pide traducción y posterior maquetación, sí podremos enviarles la traducción maquetada, en formato PDF (consultar al maquetador si también podrá enviarnos el .ai maquetado). En ese caso, durante la preparación de archivos bastará con hacer una edición convencional a Word, ya que es solo para realizar la traducción; el maquetador recreará el formato más tarde.

De cara el presupuesto, la maquetación no se presupuestará por páginas del original, ya que dependiendo del archivo, podría requerir más trabajo. Consultemos al maquetador el tiempo que estima necesario y le presupuestaremos dicho tiempo al cliente. No olvidemos que el propio item de DTP deberá superar la tarifa mínima del cliente o, si no, aplicaremos una tarifa mínima para el item DTP.

Aunque nosotros no trabajemos directamente con el archivo .ai original, sí lo utilizará el maquetador. Igual que para trabajar con InDesign, tendremos que enviarle el paquete original completo y el Word con la traducción a doble columna. El maquetador nos entregará la traducción maquetada en PDF (o/y .ai).

Traducción de formularios (templates) [PROVISIONAL, CONSULTAR CON RESPONSABLE]

El siguiente procedimento se ha acordado únicamente para la traducción de algunos formularios (templates) específicos que recibimos para traducir de PT-BR a EN. Se indica a continuación los templates específicos para los que se ha preparado, en base a los títulos en el interior de dichos formularios:

• FORMULÁRIO DE PETIÇÃO PARA ANUÊNCIA EM PROCESSO DO DOSSIÊ DE DESENVOLVIMENTO CLÍNICO DE MEDICAMENTO (DDCM) – Versão 2 de 19/12/2024 (en inglés: PETITION FORM FOR IN PROCESS APPROVAL OF CLINICAL DRUG DEVELOPMENT DOSSIER (DDCM) – Version 2 dated 12/19/2024)
• FORMULÁRIO DE APRESENTAÇÃO DE ENSAIO CLÍNICO (FAEC) – Versão 4 (en inglés: CLINICAL TRIAL SUBMISSION FORM (FAEC) – Version 4)
• FORMULÁRIO DE APRESENTAÇÃO DE ENSAIO CLÍNICO (FAEC) – Versão 6 (en inglés: CLINICAL TRIAL SUBMISSION FORM (FAEC) – Version 6)

¡IMPORTANTE! Es posible que en el futuro no se usen más estos formularios, o estas versiones. Si nos solicitan traducir formularios distintos (que cambie el contenido), en primer lugar habrá que valorar internamente si este proceso es el más eficaz para el nuevo formulario y, si lo es, requerirá crear nuevos SDLXLIFF y TM con la nueva plantilla antes de comenzar.

Identificación del documento

Reconoceremos el formulario únicamente identificando el título en el interior del documento. No podremos basarnos en el filename del archivo porque el filename no mencionará el tipo de documento sino que seguramente describirá el asunto del que trata la solicitud de aprobación.

Son documentos en portugués (de Brasil) para traducir a inglés. A continuación una imagen para ayudarnos a identificar este tipo de documentos (podría no haber ningún campo resaltado):

El cliente enviará el formulario (o standard form) que debemos utilizar para la traducción a inglés (si no, podemos pedírselo), con la siguiente apariencia:

El formulario en idioma de destino contiene ya traducidos todos los campos estándar (los enunciados y posibles respuestas que seleccionar) que debemos conservar con esa misma redacción en todas nuestras traducciones. Es decir, puesto que ya tenemos la traducción de los campos fijos, del documento original que envíen solamente habrá que traducir las respuestas (el contenido variable del formulario). También tendremos que prestar atención a las casillas, que queden marcadas o desmarcadas coincidiendo con el original.

Presupuesto

NOTA: Quizás el cliente envía la plantilla en idioma de destino y da instrucciones de pegar en ella el contenido que hay que traducir, pero le explicaremos que para ese tipo de documento en particular acordamos realizar el “template process” que ya analizamos que era el proceso más conveniente.

Se enfocará como cualquier proyecto habitual de traducción (enviarlo a editar si recibimos el original en PDF + TRA + RVW + VER). Para el presupuesto, analizaremos el original (o un OCR) en Trados con la TM habitual del cliente, aunque en el proceso de análisis haremos un paso adicional (Perfect Match) que veremos en Proceso. Si envían el original en PDF, como de costumbre, se añadirá el recuento total de palabras en Word(s) File Preparation y se sacará a editar. Si envían el original tanto en Word como en PDF, no cobraremos Word(s) File Preparation; usaremos el Word para no tener que editar, pero tengamos en cuenta que normalmente el PDF estará firmado y el Word no. También necesitarán traducir el contenido de las firmas (si no lo mencionan, confirmar con ellos). Lo más sencillo y rápido será que la propia PM incluya en el Word original el contenido de las firmas (además, si hay logos, sustituir por placeholder habitual); no es relevante incluir en el presupuesto la edición de las firmas como Word(s) File Preparation.

Además de la posible edición del PDF, para compensar el proceso de preparación especial que implican estos proyectos, se añadirán los siguientes tiempos al presupuesto:

• FORMULÁRIO DE PETIÇÃO PARA ANUÊNCIA EM PROCESSO DO DOSSIÊ DE DESENVOLVIMENTO CLÍNICO DE MEDICAMENTO (DDCM) – Versão 2 de 19/12/2024 (en inglés: PETITION FORM FOR IN PROCESS APPROVAL OF CLINICAL DRUG DEVELOPMENT DOSSIER (DDCM) – Version 2 dated 12/19/2024) → 0,5 Hour(s) File Preparation por documento.
• FORMULÁRIO DE APRESENTAÇÃO DE ENSAIO CLÍNICO (FAEC) – Versão 4 (en inglés: CLINICAL TRIAL SUBMISSION FORM (FAEC) – Version 4) → 1 Hour(s) File Preparation por documento.
• FORMULÁRIO DE APRESENTAÇÃO DE ENSAIO CLÍNICO (FAEC) – Versão 6 (en inglés: CLINICAL TRIAL SUBMISSION FORM (FAEC) – Version 6) → 1 Hour(s) File Preparation por documento.

Se han creado los SDLXLIFF correspondientes para cada plantilla que contienen la traducción de los campos fijos del formulario, tal y como deben constar en nuestras traducciones. Los encontraremos en el servidor Nextcloud TMs > PT-EN-Medical > PSI > Templates. Para doble seguridad, también se pueden encontrar en Dropbox. De cada plantilla se ha guardado: Word original (plantilla vacía), SDLXLIFF, TM con solo ese contenido. El Word original contiene variantes de algunas frases que por motivos de edición podrían ser ligeramente diferentes (por ejemplo, espacios, checkboxes, negritas, etc.). Lo guardamos porque en el futuro podría interesarnos actualizarlo con otras variantes/frases y ampliar el SDLXLIFF/la TM para estos proyectos.

Cada formulario que tengamos que traducir lo analizaremos en un proyecto en Trados, cargando la TM habitual del cliente y, en el paso Perfect Match del asistente, cargaremos este SDLXLIFF que contiene la traducción de los campos fijos, que identificará esos campos en nuestro original, los traducirá como en el SDLXLIFF y bloqueará dichos segmentos.

Si estamos realizando la preparación del Word limpio que sacaremos a traducir sí es importante que todos los campos fijos queden debidamente traducidos y bloqueados. Sin embargo, si lo que estamos analizando es un OCR sucio, únicamente para el presupuesto, según la calidad del OCR podríamos ver que algún campo fijo no se ha detectado y bloqueado. No pasa nada, para el presupuesto nos sirve que sea aproximado. Eso sí, si son muchos los campos fijos que no ha detectado, entonces sí interesará dedicar un par de minutos a bloquear todos los segmentos que identifiquemos como campo fijo (con bloquearlos basta. Ya haremos bien la preparación con el Word limpio).

El recuento obtenido tras volver a analizar el SDLXLIFF con los segmentos bloqueados es el que aplicaremos en el presupuesto al cliente.

IMPORTANTE: Recuerda excluir los segmentos bloqueados del análisis:

Proceso

Al confirmarse el proyecto, en primer lugar, enviaremos el documento a editar (si el original lo tenemos en PDF). Si ya contamos con el original en Word, nos aseguramos de incluir el contenido de las firmas, el PSI-footer o cualquier información que pueda faltar y comenzamos el proceso de preparación.

• PASO 1

Cuando tenemos el Word original editable, crearemos el proyecto. En el paso de Recursos de traducción, no añadimos la TM del cliente sino la TM específica que solo contiene la traducción de los campos fijos de la plantilla. De este modo, tendremos la tranquilidad de que todas las sugerencias de esta TM son únicamente de los campos fijos.

Desmarcamos “Actualizar” como siempre.

En el paso de Tareas por lotes, buscamos en el árbol Pretraducir archivos y configuramos el valor mínimo de coincidencia en 85%. De este modo salvaremos posibles diferencias de formato que podría haber en nuestro original y podremos encontrar igualmente la traducción de esos campos fijos en la TM.

• PASO 2

Abrimos el documento para traducir. Veremos los siguientes tipos de segmentos:

• • Segmentos 100% match y Context Match (CM), que corresponden a campos que ha encontrado idénticos en la TM. Esos segmentos están confirmados.
  • Segmentos en borrador para los que ha encontrado una coincidencia en la TM, pero parcial (85%-99%), probablemente debido a ligeros cambios de contenido/de formato. Estos son todos los segmentos que, uno a uno, deberemos revisar, retocar (si procede) y confirmar.
  • Segmentos vacíos, con los que no hay que hacer nada. Serán todos los campos variables que hay que traducir.

Así pues, recorremos el documento parándonos al encontrar un segmento en borrador y hacemos los pequeños ajustes que cada segmento pueda requerir para conservar la traducción exacta que debemos conservar pero, a su vez, hacer que coincida totalmente con nuestro segmento original:

En algunos casos, la coincidencia no llega a ser al 100% por cuestiones de formato que no son visibles en Trados, pero no es que la traducción requiera ningún cambio (ej. segmento 63, abajo); simplemente confirmaremos el segmento.

También puede afectar la propia edición de nuestro original, si la frase tiene un espacio de más o de menos, o un símbolo, etc. (ej. segmento 49, abajo). En estos casos, no modificaremos la traducción que ofrece la TM. Sin embargo, en los casos de los segmentos 99 o 242 (arriba), sí es relevante añadir un guion o dos puntos, si salen en nuestro original.

• PASO 3

Cuando tenemos todos los campos fijos revisados y confirmados, filtraremos todos esos segmentos (estado “Traducido”).

Seleccionamos todos los segmentos filtrados, los cambiamos de estado a “Borrador” y los bloqueamos. El estado “Borrador” evitará que esos textos pasen a la TM cuando la actualicemos en el futuro con el SDLXLIFF traducido.

Finalmente, quitamos el filtro para volver a ver todos los segmentos y guardamos el SDLXLIFF para traducir.

Teniendo ya el SDLXLIFF preparado podemos proceder a analizarlo con la TM del cliente para obtener el recuento para el traductor (por supuesto, excluyendo los segmentos bloqueados del análisis). Podemos explicar al traductor que los segmentos bloqueados son campos fijos que debemos respetar como están y no deben modificar.

Realizaremos nuestro control de calidad con normalidad y, en principio, sin necesidad de preocuparse por revisar los campos fijos porque ya han quedado atendidos en la preparación. No es relevante desbloquear esos segmentos antes de guardar el SDLXLIFF traducido.