NVCR

1. Descripción

Esta ficha comprende los siguientes clientes de Plunet:

• NVCR GmbH: 1222
• NVCR GmbH (Germany): 1764
• NVCR Austria GmbH: 2907
• NVCR Inc.: 1252
• NVCR Italy S.R.L.: 2970
• NVCR Spain S.L.: 2990
• NVCR UK Limited: 2996

2. Notas generales

2.1 Introducción al cliente

NVCR es una empresa de dispositivos médicos que investiga los campos eléctricos para el tratamiento de tumores (TTFields) como una alternativa terapéutica para diversos tipos de cáncer.

Los TTFields son campos eléctricos que alteran la división de las células cancerosas y se administran en la región del tumor mediante un dispositivo médico portátil no invasivo. Este dispositivo funciona con batería y se ha diseñado para que los pacientes puedan continuar con su estilo de vida y actividades habituales sin interrupción.

NVCR es el fabricante del dispositivo y el promotor de varios estudios clínicos que investigan la terapia con TTFields para diferentes tipos de cáncer.

El tratamiento con TTFields está autorizado en pacientes adultos con glioblastoma multiforme (GBM) recidivante (en monoterapia) y de diagnóstico reciente (en combinación con un fármaco quimioterápico llamado temozolomida) mediante una solicitud de autorización de comercialización (PMA) en Estados Unidos. Se han conseguido el distintivo CE en Europa y la autorización en Japón para la misma indicación. El uso de TTFields junto con quimioterapia también ha obtenido el distintivo CE en Europa y se ha autorizado para el tratamiento de pacientes adultos con mesotelioma pleural maligno (MPM) a través de la vía de exención para un dispositivo por motivos humanitarios (HDE) de la FDA.

2.2 Puntos importantes comunes y conceptos básicos

• TODOS los trabajos llevan quote y CoT aunque no lo mencionen.
• Los e-mails que llegan con el asunto “Secure Messaging Notification” son solicitudes que NVCR envía a través de un portal especial. Para acceder, hacemos clic en el enlace que indica el e-mail y utilizamos el usuario y contraseña indicado en el Excel compartido “Owncloud/Groupshare/Iuratum – Okodia”, en la pestaña “Clientes”.

Una vez se reciben solicitudes a través de este portal, debemos contestar por el mismo medio; aunque no nos va a dejar añadir en la copia a nuestra cuenta de email específica para este cliente si previamente ellos no la han incluido al mandar el email a través de este portal.

• NO podemos enviar traducciones previas a una persona diferente de la que solicitase en su día dicha traducción, a menos que esta petición vaya acompañada de una aprobación por escrito de un General Manager, Vice President, Senior Vice President, Head of Global Clinical Operations, o Clinical Operations Director of Novocure. El redactado exacto de esta cláusula se encuentra en el MSA de la carpeta del cliente en Plunet (artículo 9.1 del MSA Novocure Okodia fully executed.pdf, y su posterior segunda enmienda en el MSA-2ndAmendment-20240930.pdf).
• Cada solicitud debe tener su estudio específico siempre seleccionado en Plunet (EF-32, EF-14, RA, etc.), a excepción de los departamentos de Marketing, que no llevarán ningún estudio asignado por norma general pero SIEMPRE necesitarán un nº de PO para facturar (para más información consultar el apartado 3. Facturación para gestión de proyectos).

Hay plantillas específicas para la creación de quotes en Plunet (seleccionando “Quote from template”):

* No existen plantillas para los departamentos de Marketing de NVCR (Germany) y NVCR (GmbH) debido a los detalles de facturación que se desarrollan en el apartado 3.

• Los documentos englobados en el estudio EF-28 están dirigidos exclusivamente a enfermos oncológicos del género femenino.
• Como en el apartado “Study Titles” del CRM no deja copiar en formato editable los títulos de los estudios en árabe, se puede acceder a ellos en formato Word en la carpeta del cliente en Plunet.
• Para la revisión de trabajos con búlgaro, checo, croata y serbio como lenguas target, es importante cargar o elegir en Xbench las checklist correspondientes (disponibles en Sharepoint\PM\TMs\Terminology\Medical\Multiterm\xbench) a la hora de hacer el control de calidad. Para más información, consultar “Resource 02 – Xbench, Guía rápida”
• Cosas que tenemos que saber antes de empezar a gestionar un proyecto de NVCR:

1. ¿A quién se factura?
2. ¿A qué departamento pertenece?
3. ¿Es para un estudio específico?
4. ¿Lleva PO global o individual?
5. ¿Qué tipo de servicio solicitan?

3. Facturación para gestión de proyectos

En NVCR nos envían solicitudes desde varios países y departamentos y, dependiendo cuál esté implicado, su facturación será diferente. La firma de los contactos en sus correos nos podrá dar una pista bastante útil, pero hay otros factores que nos pueden ayudar a identificar el país o departamento. Por supuesto, ante la duda, SIEMPRE preguntaremos al cliente.

Tenemos siete posibles países/nombre de empresa a facturar en Plunet:

• Suiza – cliente 1222
• Alemania – cliente 1764
• Austria – cliente 2907
• Italia – cliente 2970
• España – cliente 2990
• Reino Unido – cliente 2996
• EE. UU. –cliente 1252

Además, tenemos cuatro posibles departamentos:

• Clinical Operations (ClinOps)
• Regulatory Affairs (RA)
• Marketing y DSS Operations EMEA
• Communications

Además, hay que tener en cuenta tres campos en Plunet, que serán los que varíen según el país y procedimiento:

• El campo PO NVCR

Este campo es exclusivo para este cliente y se encuentra específicamente, dentro del presupuesto u order, en la sección General > Text Modules. En este desplegable tenemos listados todas las POs globales disponibles. Si no utilizásemos ninguna de ellas, este desplegable quedará en blanco:

Hay ciertos casos en los que no se utilizan POs globales sino individuales. Si es así, el campo PO NVCR permanecerá vacío y anotaremos la PO correspondiente en cada Cost Center del Item, que se transferirá una vez lo pasemos a Order:

• ¿A quién va dirigido el presupuesto?

La norma general es dirigirlo a aquella persona que hace la solicitud con la excepción de RA, que estará dirigida siempre a una persona en concreto (información desarrollada en el punto 5.)

3.1 Clinical Operations (ClinOps)

En este caso los trabajos normalmente vienen desde Suiza (NVCR GmbH), aunque también hemos recibido solicitudes desde EE. UU. (NVCR Inc.).

• Para NVCR GmbH

En este caso, todos los proyectos pertenecerán a una PO global que actualizan cada año. Por lo tanto, y para evitar complicaciones, siempre crearemos los presupuestos en Plunet a partir de la plantilla de presupuestos del estudio correspondiente, que ya incluye dicha PO.

En el desplegable PO NVCR, utilizaremos la PO correspondiente al estudio al que pertenece el documento.

Solamente se sale de la norma aquellos trabajos que ellos específicamente nos digan que tienen una PO independiente, en cuyo caso dejaremos el desplegable de la PO global vacía y anotaremos la PO correspondiente en el Cost Center del Item.

• Para NVCR Inc.

Por norma general, para NVCR Inc., siempre necesitaremos una PO antes de comenzar y no empezaremos el trabajo sin antes recibirla, sin excepciones. Ésta se incluirá en el Cost Center del Item o Items del trabajo. El campo PO NVCR permanecerá en blanco.

3.2 Regulatory Affairs (RA)

• Para NVCR GmbH

En este caso, la empresa que siempre figurará en el presupuesto será NVCR GmbH (Suiza), aunque nos lo pida alguien del equipo desde EE. UU.

Además, no importa quién envíe el correo con la solicitud, estará a nombre de K.L.

En este caso, las POs son diferentes en cada trabajo y nos las incluirán en el documento Request Form que adjuntan en cada solicitud. Este documento indica, entre otras cosas, la PO de cada idioma o grupo de idiomas, que introduciremos en el Cost Center de los Items correspondientes:

Esto implica que en desplegable PO NVCR dejaremos siempre la opción «RA»:

Para minimizar los errores, a la hora de crear presupuestos siempre utilizaremos la plantilla «NVCR GmbH – RA».

Esta plantilla tendrá por defecto al contacto que nos pidan y el campo de PO NVCR como «RA».

3.3 Marketing y DSS Operations

El departamento de DSS Operations llevará una PO independiente para cada trabajo que siempre nos facilitará la persona que nos pide el encargo.

El caso de Marketing es el más complicado y es muy recomendable confirmar con el cliente la información. Lo normal es que las solicitudes vengan de Alemania (NVCR GmbH (Germany)), Suiza (NVCR GmbH) o Austria (NVCR Austria GmbH).

• Para NVCR GmbH (Germany)

En el caso de NVCR GmbH (Germany), siempre vamos a tener una o dos PO anuales con un determinado presupuesto (tendremos una PO para el equipo de NIT y otra para el equipo de CNS. La información correspondiente a las PO siempre estará indicada y actualizada en el memo de NVCR (Germany).

Existirá también una master order para cada PO existente, por lo que será extremadamente importante y obligatorio que todas las order que se facturen con las PO globales de este departamento estén englobadas dentro de la master order que corresponda. De este modo, desde PM podemos llevar un control del remanente de dinero que vaya quedando en esas PO.

En caso de que necesitemos hacer un presupuesto que vaya a agotar el remanente de alguna de las PO globales es obligatorio avisar al cliente de que deben aumentar la PO y no empezar el trabajo hasta que confirmen una nueva PO o el aumento de dinero en la misma.

 

Sin embargo, aun teniendo toda esta información, es muy conveniente confirmar con el solicitante si debemos utilizar cualesquiera de las PO globales o si debemos utilizar una PO individual para el trabajo que nos estén solicitando. Si es el caso segundo, hemos de recibir la PO antes de comenzar e incluirla en el Cost Center del Item o Items del trabajo. El campo PO NVCR permanecerá en blanco.

• Para NVCR GmbH

Aplica exactamente la misma información que para NVCR (Germany).

• Para NVCR Austria GmbH

Cuando los trabajos provengan de Austria, NO será necesario una PO ni nada similar: simplemente con su confirmación nos basta. Hay que asegurarse de que no figura ninguna PO por ningún lado del presupuesto u order.

En cualquier caso, tenemos una plantilla de presupuestos a nuestra disposición llamada NVCR GmbH (Austria) – Marketing.

• Para NVCR Italy S.R.L., NVCR Spain S.L y NVCR UK Limited

Italia, España y Reino Unido son también mercados nuevos en los que no se ha implementado un sistema que pueda generar POs, por lo que NO será necesario una PO ni nada similar: simplemente con su confirmación nos basta. Hay que asegurarse de que no figura ninguna PO por ningún lado del presupuesto u order.

Por el momento no se han creado plantillas para estos mercados, ya que el volumen de trabajos que hemos recibido hasta ahora no es representativo.

• Para NVCR Inc.

Si se diese el caso, siempre será necesaria una PO antes de comenzar, sin excepciones. Ésta se incluirá en el Cost Center del Item o Items del trabajo. El campo PO NVCR permanecerá en blanco.

3.4 Communications

En este caso, por norma general se facturarán en base a la PO global de cada estudio (es decir, como ClinOps), y utilizaremos la plantilla que nos convenga, dependiendo del estudio.

En algunas ocasiones, nos mandan documentos que no pertenecen a ningún estudio en particular y que utilizan para todos los estudios. Estos documentos llevarán el identificador «Universal» en el pie de página o el nombre del archivo y se facturarán bajo la PO llamada «General/non-study», que también se encuentra en el desplegable.

Si no tuviésemos clara esta información, es conveniente confirmar con el solicitante si podemos utilizar la PO global o si debemos utilizar una PO individual. Si es el caso segundo, hemos de recibir la PO antes de comenzar e incluirla en el Cost Center del Item o Items del trabajo. El campo PO NVCR permanecerá en blanco.

4. Proyectos para el departamento de ClinOps y Communications

Los trabajos de ClinOps, a grandes rasgos, incluyen la correspondencia con las autoridades y materiales para paciente tales como los ICFs, aunque también pueden llegar a mandar algún otro tipo de documento (una sinopsis, por ejemplo).

Es un departamento que trabaja junto con el de Communications. Este último trabaja con documentos dirigidos a pacientes: no solo ICFs, pero también contenido de la web, pósters, letters, etc.

Suelen trabajar con Word y PDF, pero estos documentos para pacientes pueden venir en un formato editable INDD, PPTX… Si envían un PDF solamente, podemos preguntarles si tendrían la versión editable por un casual. Además, hay veces que necesitan DTP, así que es conveniente consultarlo con ellos.

En este caso los trabajos normalmente vienen desde Suiza (NVCR GmbH), aunque también hemos recibido solicitudes desde EE. UU (NVCR Inc.). Hay que fijarse en la firma en caso de ser un contacto nuevo para saberlo, pero se ha de tener en cuenta que muchas veces, aun mandándolo gente desde EE.UU., se factura para Suiza (para más información consultar punto 3.).

4.1 Materiales

Memorias de traducción*:	NVCR NVCR_BACK-TRANSLATIONS	Terminología:	NVCR
*En caso de ser una combinación poco común, probaríamos a usar la TM medical (si existiese) a ver si es útil.

4.2 Correspondencia con autoridades

Normalmente enviarán PDFs que editaremos y traduciremos siguiendo el procedimiento habitual. Se procesará con el total de palabras +10%.

Es posible que haya excepciones puntuales, tales como un lote grande de PDFs muy similares o casi iguales a simple vista. En estos casos, procederemos de la siguiente manera:

1. Haremos los OCR de todos los archivos y crearemos un proyecto en Trados con el Word resultante, sin incluir la TM del cliente.
2. Con el log resultante, crearemos el presupuesto en Plunet, dejando el coste de las repeticiones a 0.
3. Para presupuestar la edición de los archivos, calcularemos el 10% del recuento total del OCR e incluiremos esas palabras como si fueran nuevas.
4. Para calcular el plazo al cliente, hay que tener en cuenta que no se revisarán las repeticiones, pero la PM encargada tendrá que bloquear esas repeticiones al traductor y desbloquear y dejar todo traducido en los archivos finales antes de proceder con el control de calidad. Por ello, es importante tener ese tiempo de gestión en cuenta para calcular el plazo al cliente.
5. Finalmente, pasaremos al cliente el presupuesto generado con la plantilla CAT discount y les indicaremos que, como los documentos son muy similares, les incluimos un recuento por repeticiones. Así:

*IMPORTANTE: al generar la plantilla del presupuesto como CAT discount, la línea del descuento saldrá como “TM discount”. Con el objetivo de minimizar las dudas del cliente, cambiaremos esta frase a “Repetitions discount” antes de generar el PDF y mandarlo al cliente para su aprobación.

4.3 Documentos dirigidos al paciente

Debemos recordar que por defecto necesitan solo traducción + back-translation + revisión de back-translation (confirmar siempre con el cliente lo que estamos incluyendo en el presupuesto al enviarlo). Nos han enumerado los documentos dirigidos a pacientes que requerirán back-translation; esta fase se presupuestará cogiendo el total de palabras +10%:

• Subject Information Sheets
• Clinical Trial Poster
• Website text
• Media Kit
• Patient Wallet Card
• Troubleshooting Guide
• Quick Start Guide
• Starting NovoTTF Booklet
• Skin Care Guide
• Air Travel Packet
• Mobile Travel Cart Instructions
• MyLink Patient Letters
• ICF: en este caso, el flujo de trabajo para los documentos ICF para este departamento será el siguiente: traducción + revisión. En caso de solicitar explícitamente la necesidad de hacer back-translation, también se añadirá la revisión de la back-translation. Por lo tanto, en el supuesto de recibir un ICF que requiera back-translation, el flujo de trabajo completo será: traducción+revisión+back-translation+revisión de back-translation. El flujo de trabajo compete tanto a traducciones nuevas como a trabajos con TC.

Para este tipo de trabajos que llevan revisión por un segundo lingüista es importante recordar que tenemos que cambiar el campo “Project category” (de “Translation” a “Translation and Review” y la “Quality (ISO)” correspondiente en Plunet).

(Consultar documento “CTC-20230523.pdf», dentro de la carpeta DatosCliente-Instructions2ndReview, para ampliar la información sobre los proyectos para el departamento de Communications.)

Al total de palabras de back-translation le añadiremos el presupuesto de las horas de revisión correspondientes.

Recordemos utilizar la terminología en ambas fases del proyecto: tanto en la traducción directa como en la back-translation.

En lo que respecta las variantes origen de algunos países, no se indicarán en los presupuestos, exceptuando los siguientes casos:

• Dutch (NL-nl) y Flemish (NL-be) se considerarán idiomas independientes, por lo que sí se hará esta diferenciación por defecto si son idioma origen en los presupuestos de las BTs. Sin embargo, en cuestión de las TMs, solamente habrá una TM NL > EN.
• Si NVCR pidiese la back-translation de dos variantes a la vez (francés de Francia + francés de Canadá, portugués de Portugal + portugués de Brasil, etc.), en esos casos sí se indicará la variante source en los presupuestos de las back-translation, dado que Plunet no permite crear dos ítems con la misma combinación de idiomas. La TM seguirá siendo única (FR > EN, PT > EN, etc.).

Cualquier otro documento dirigido al paciente que haya sido solicitado por el departamento de Communications y que no esté en la lista citada más arriba necesitará traducción + revisión y no será necesario realizar el paso de back-translation.

4.4 Documentos para RA

Incluye sinopsis, autorizaciones de RA, etc. pero con menos frecuencia. Aunque por lógica se considerarían documentos para el departamento de RA (utilizando sus materiales específicos), dado que lo envía ClinOps, procedemos siguiendo las normas de este departamento salvo excepciones, dado que no podemos compartir los materiales del departamento de RA con nadie más sin su permiso. De todas formas, siempre ante la duda, preguntaremos al cliente.

Por defecto, estos trabajos se presupuestarán sin revisión adicional, aunque es conveniente matizarlo en nuestros correos, dado que nos han pedido ambas cosas.

En principio, estos trabajos no requerirán back-translation.

4.5 Documentos legales

Podrán ser NDAs, CTAs… No suelen mandar a menudo, y pueden pedir que lo enviemos a doble columna:

• Confirmaremos con el cliente qué tipo de servicio quieren, si no lo especifican de antemano.
• Si piden que lo entreguemos a doble columna, si no nos lleva mucho tiempo, no meteremos ningún coste por preparación (esto será lo normal). Si vemos que es un documento complicado porque tiene un formato malo, valoraremos incluir un tiempo de preparación en el presupuesto.
• Para documentos GDPR, será obligatorio el uso de la termbase “legal_GDPR_termbase”, para adecuar los textos a la normativa europea.

4.6 Footers

Correspondencia con autoridades	No hace falta hacer nada con los pie de página de la correspondencia con autoridades que nos envíen: simplemente se intenta emular el original.
ICFs	Se debe dejar el nombre de archivo en inglés (es decir, facilitar que ellos lo puedan identificar), con los códigos referentes al idioma adaptados. Además, añadiremos una nueva línea incluyendo la fecha de entrega de la traducción, siguiendo el esquema [Language] translation dated dd Month yyyy; es decir: Spanish (US) translation dated on 29 March 2023 Para trabajos con track-changes, habrá que añadir [Language] translation updated on dd Month yyyy: Spanish (US) translation updated on 29 March 2023 Para trabajos de back-translation, habrá que añadir [Language] back-translation dated/updated on dd Month yyy: Spanish (US) back-translation dated on 29 March 2023 Es importante recalcar que en el caso del serbio y del croata toda esta información de los pie de página tiene que ser bilingüe.
Subject Information Sheets Clinical Trial Poster Website text Troubleshooting Guide Quickstart Guide Starting NovoTTF Documents Skin Care Guide Air Travel Packets, etc.	Todos los pie de página u otros elementos identificativos de estos documentos que pueden aparecer solo al final deben ser bilingües, quedando el inglés al final, en la última línea, y adaptando los códigos de idioma al de la traducción. En los casos en los que el documento no pertenece a un estudio en particular y aparece la palabra «Universal», esta deberá traducirse al idioma correspondiente. Si se trata del pie de página de una back-translation, dejaremos solamente el texto original en inglés añadiendo _BT al final. En lenguas que se leen de derecha a izquierda (como el hebreo o el árabe), el pie de página en inglés deberá justificarse a la derecha pero el texto deberá leerse de izquierda a derecha. Este Excel debe usarse como referencia, con una lista más exhaustiva.
Documentos de RA	Mantenemos el nombre identificativo en inglés si lo hubiere, ajustando el código del idioma.
Documentos legales	Normalmente nos pedirán documentos bilingües, así que procuraremos que el pie de página sea bilingüe también salvo que especifiquen algo.

4.7 Creación de certificados para ClinOps y Communications en el CRM

Para los proyectos estos dos departamentos se ha convenido usar una plantilla específica de Certificado de Traducción disponible en el CRM.

Crearemos un certificado por documento utilizando la plantilla de cliente “NVCR-ClinOps-CTC”.

Aquí escogeremos el idioma origen, el idioma de destino y tendremos que indicar el nombre del archivo original en el campo “Description” y el nombre del archivo traducido en el campo “Translated document/s”. Además, indicaremos también las siglas del traductor (y del revisor en caso haberse tratado de un trabajo de T+R). A continuación tenemos un ejemplo de cómo nombrar los archivos:

Original en hebreo:         EF-32_14-503_Internal Audit Report_final_24Jan2023_HE.docx

Traducción en inglés:      EF-32_14-503_Internal Audit Report_final_24Jan2023_EN.docx

Certificado:                        EF-32_14-503_Internal Audit Report_final_24Jan2023_EN_CoT.pdf

Además, si el trabajo fuese de cambios marcados, actualizaríamos la información que aparece en el nombre de archivo, tales como la versión y la fecha, y devolveríamos tanto la versión con cambios (TC) como la limpia *:

Original en inglés:                  EF-28_EN_ICF_Germany_v.9.0_23Sep2022_TC.docx

Versión inicial en alemán:   EF-28_DE_ICF_Germany_v.8.0_28Apr2022_TC.docx

Traducción en alemán:         EF-28_DE_ICF_Germany_v.9.0_23Sep2022_TC.docx

EF-28_DE_ICF_Germany_v.9.0_23Sep2022.docx

Certificado:                               EF-28_DE_ICF_Germany_v.9.0_23Sep2022_TC_CoT.pdf

*En las versiones limpias, no habrá ni TC marcados ni comentarios. Además, no se añadirá un “_clean” en los filenames. Todos los comentarios que haya que dejar al cliente, se marcarán solamente en la versión con TC.

Para las back-translations usaremos el nombre de archivo de la forward translation y clicaremos en el campo “Back-translation” para que el certificado se genere correctamente.

Original en inglés:            EF-32_TRIDENT_Document name_v1_EN_24Jan2023.docx

Traducción en hebreo:   EF-32_TRIDENT_Document name_v1_HE_24Jan2023.docx

Back-translation en inglés: EF-32_TRIDENT_Document name_v1_HE_24Jan2023_BT.docx

Certificado:                        EF-32_TRIDENT_Document name_v1_HE_24Jan2023_BT_CoT.docx

Si tuviéramos que generar varios certificados porque nos pidan la traducción a más de un idioma, en “Idiomas destino” escogeremos los idiomas que corresponda. Después en “Name of the translator” indicaremos las iniciales de los traductores que corresponda en orden de aparición del idioma en el campo “Idiomas destino”. De este modo, si se ha traducido un documento a checo, alemán y sueco, en la primera línea aparecerán las iniciales del traductor de checo, en la segunda las del traductor de alemán y en la tercera las del traductor de sueco:

Para el campo “Translated document/s” utilizaremos las tags disponibles para sustituir el idioma del documento origen por los idiomas del documento de destino.

• • {{IDIOMA_DESTINO}}:Se sustituirá por el código (y variantes si las tiene) de idioma de destino elegido.

Es decir, en el caso del portugués de Portugal, escribirá ambos “PT_PT” y “PT_BR”.

• • {{NOMBRE_IDIOMA}}: Se sustituirá por el nombre de idioma de destino elegido.

En otras palabras, en lugar de escribir “PT”, escribirá “Portuguese” en el nombre del certificado.

• • {{CODIGO_IDIOMA}}: Se sustituirá por el código de idioma de destino elegido.

Volviendo al primer ejemplo, en el caso de portugués no se especificaría variante: solamente escribiría “PT”.

• • {{CODIGO_VARIANTE}}: Se sustituirá por el código de variante (si la tiene) del idioma de destino elegido.

En este caso, escribirá el código de la variante del idioma de destino que hayamos elegido en el desplegable un poco más arriba. En el caso del portugués escribirá “pt” o “br”.

OJO: Es importante recordar que siempre hay que copiar e incluir los pares de corchetes para que funcione la etiqueta.

4.8 Entregas

Normalmente las haremos vía Plunet. Sin embargo, si el hilo fuese muy enrevesado y se prefiere, se puede valorar devolverlo vía Gmail sin mayor problema manteniendo siempre en copia a nuestra cuenta de correo para este cliente.

Para el departamento de Communications, se han acordado una serie de pautas para las entregas dependiendo del tipo de proyecto y del formato en que recibamos los originales. Dichas pauta se detallan a continuación:

1. Traducción de un documento Word sin control de cambios

Entrega: documento en el mismo formato que el original (Word) con el pie de página bilingüe y el código de idioma actualizado en el pie de página y en el nombre de archivo.

Ejemplo: GP Letter v2 (EN to ES)

2. Traducción de un documento Word con cambios marcados

Entrega: documento en el mismo formato que el original (Word)

Ejemplo: GP Letter V1 to V2 tracked Changes ES

Flujo de trabajo: recibimos el documento GP Letter V2 en EN

Lo traducimos al español (traductor A)

NVCR nos manda la versión anterior traducida. Si no, recuperamos la GP Letter V1 ES que estará o bien en Plunet, o bien archivada en Dropbox (si no viola el MSA).

Generamos el documento con control de cambios partiendo de la GP Letter V1 y la V2 que acabamos de traducir.

Nombre de archivo del documento traducido: EF-xx_Study Name_GP Letter_v1 to v2 tracked changes_v1_ES_ddmmmyyyy

3. Traducción de un documento Word con cambios marcados

Entrega: documento en el mismo formato que el original (Word)

4. Traducción de un documento InDesign:

Entrega: documento en formato IDML y PDF (sin maquetación ), con el pie de página bilingüe y el código de idioma actualizado en el pie de página y en el nombre de archivo.

Ejemplo: Clinical Study Poster v2 EN to ES

5. Traducción de cambios marcados de un documento que originariamente está en formato InDesign

Entrega: comparación en formato Word con los cambios visibles

Ejemplo: Clinical Study Poster v1 to v2 tracked changes ES

Flujo de trabajo: recibimos el documento Clinical Study Poster V2 en EN, en formato IDML

Lo traducimos al español (traductor A), en formato IDML (con maquetación)

NVCR nos manda la versión anterior traducida. Si no, recuperamos el Clinical Study Poster V1 ES que estará o bien en Plunet, o bien archivado en Dropbox (si no viola el MSA).

Convertimos la versión 1 y la versión 2 en español a Word en texto plano.

Generamos el documento con control de cambios (en formato Word) comparando el Clinical Study Poster V1 y la V2 que acabamos de traducir.

Nombre de archivo del documento traducido: EF-xx_Study Name_Clinical Study Poster_v1 to v2 tracked changes_v1_ES_ddmmmyyyy.docx

6. Back Translation de un documento InDesign

Entrega: documento en formato IDML + PDF (sin maquetar)

5. Proyectos para el departamento de Regulatory Affairs (RA)

Nota previa: es importante recordar la posibilidad de externalización del QA o parte del QA, como se explica en el apartado 9.1 del PM001.

Este departamento trabaja principalmente los protocolos (CIP), manuales del investigador (IB) y manuales del usuario (UM).

En este caso, la empresa que siempre figurará en el presupuesto será NVCR GmbH (Suiza), aunque nos lo pida alguien del equipo desde EE. UU. Además, no importa quién envíe la solicitud, estará a nombre de K.L.

En este departamento las POs son diferentes en cada trabajo y nos las incluirán en el documento Request Form que siempre deberían adjuntar en cada solicitud (para más información, véase «0 NVCR – Facturación para PM» disponible en el perfil del cliente en Plunet).

5.1 Materiales

Memorias de traducción:	NVCR_Regulatory	Terminología:	NVCR_Regulatory
Guía de estilo:	WI-RA-002_Rev01_Style guide for the Translation of Regulatory Documents

*El uso de la guía de estilo para los trabajos de RA es obligatorio para los traductores a la hora de traducir y las PM para revisar los trabajos. Es de suma importancia que la PM encargada de la gestión se lea y conozca tanto las pautas de la guía de estilo como las instrucciones de Plunet (que aparecen más adelante en el siguiente apartado) para poder solucionar las posibles dudas a los traductores.

5.2 Protocolos, manuales del investigador y manuales del usuario

No necesitan segunda revisión y normalmente solicitarán también la back-translation correspondiente.

Los archivos pueden ser demasiado pesados, en cuyo caso subirán los archivos al servidor de Sharepoint > PM > Clients > NVCR > ToOkodia.

Si nos piden traducir un documento desde cero hacia cierto idioma con su correspondiente back-translation y su log tiene una cantidad bastante significativa de fuzzies, reflejaremos un descuento equivalente al de las traducciones directas en las back-translations añadiendo un 10% al resultado del log, no al total de palabras. Aplicamos esta excepción dado que sus TM hacia inglés están compuestas de back-translations principalmente, pero avisaremos al cliente de que a lo mejor el presupuesto de la back-translation habrá que actualizarse más adelante si resulta que al comenzar el proceso la TM nos ayuda mucho menos de lo esperable.

*Ejemplo:

10.000 palabras totales, 5000 repeticiones: al cliente le presupuestamos 7500 en la FT; en la BT le presupuestaríamos 7500 + 10% = 8250 palabras.

En el caso de las BT de japonés multiplicaremos las palabras del original por 2,5.

Las traducciones tenderán a la literalidad obligatoriamente y no hay lugar para interpretaciones del archivo source. Siempre seguiremos la terminología, tanto en traducciones directas como en back-translations.

Además, siguiendo el procedimiento general, no indicaremos variantes en los idiomas origen de los presupuestos. Sin embargo, tengamos en cuenta lo siguientes matices:

• Dutch (NL-nl) y Flemish (NL-be) se considerarán idiomas independientes, por lo que sí se hará esta diferenciación por defecto si son idioma origen en los presupuestos de las BTs. En cuestión de las TMs, tenemos dos: una TM NL > EN y otra NL-be > EN.
• Si NVCR pidiese la back-translation de dos variantes a la vez (francés de Francia + francés de Canadá, portugués de Portugal + portugués de Brasil, etc.), en esos casos sí se indicará la variante source en los presupuestos de las back-translation, dado que Plunet no permite crear dos ítems con la misma combinación de idiomas. La TM hacia inglés seguirá siendo única (FR > EN, PT > EN, etc.).

Por otro lado, subiremos la Request Form que nos envían dentro de Plunet, al mismo nivel que la carpeta «Source» (no dentro). Dentro del Request Form, además de otra información importante como el plazo, los idiomas o la PO, nos incluirán cómo llamar a los certificados de traducción: copiaremos esta lista en el memo para facilitar nuestra tarea en la entrega.

En los jobs de este departamento siempre marcaremos la casilla «Download» para compartir su guía de estilo específica.

Además, si tenemos un trabajo de manuales entre manos, podemos compartir la siguiente información en el espacio para comentarios como recordatorio para los traductores (recuerda adaptar lo que sea necesario en cada trabajo, esto es solo una plantilla y tampoco incluye todas las indicaciones de la guía, solo las que suelen resultar más problemáticas):

– This job is for the RA department, so please take into account the following instructions:

> Please read the style guide from the NVCR’s Regulatory Affairs department. It is available in Plunet so please, take a look at it.

> Please, follow the terminology provided by the termbase. If you strongly disagree with anything, please let us know but for now keep using the term included in the termbase.

> Please, only use the corresponding medical-NVCR-Regulatory TM (not the medical one nor the generic one for NVCR). You can find it either on Groupshare or in the reference folder/Trados package.

> Try to minimize modifications to the fuzzies so the translation is as consistent as possible with past documents. Nevertheless, we have added some extra time in the PO to compensate to the fact that we still have to be careful with all fuzzies and make sure they comply with the style guide and termbase.

> Among other things enumerated in the style guide and to quickly sum up, remember to:

1) keep the word “TTFields” in English and do NOT add “fields” in your translation even if your language needs to: consider TTFields as a proper name.

2) Please also consider “Optune/Optune Lua”, “NovoTTF-200T”, etc. as proper names and leave them in English.

3) Keep the expression “INE Transducer Arrays”/“ILE Transducer Arrays”/“ITE Transducer Arrays” in English – you can consider them as proper names too. However, when “transducer array” appears alone (this is, without the acronym INE/ILE/ITE) then please, translate it into your language as any other regular noun (using the term included in the termbase).

> Translate literally, sticking to the current source.

> Keep the words “BATTERY”, “POWER”, “TTFIELDS”, “ON/OFF” in English and add the translation in your language between brackets afterwards. The reason is that these words are actually displayed on the device.

> Keep units of measure in the same unit as the source, even if it is not the common measure in your country (I am thinking about inch vs. cm, for example). In other words: if only inches appear in the source, only inches can appear in the translation.

> Please also remember the differences between “power source” and “power supply”. The concept of “power source” includes both “sources” for the device: the batteries and the power supply (this is, an AC adapter plugged into an outlet).

> Also remember that, if possible, “therapy” should be translated as “therapy” and “treatment” as “treatment” (this is, two different, literal words) even if it implies not being 100% correct. There are languages that tend to use “therapy” in a psychological context; if this is the case in your language too please, let us know so we warn the client but still, use “therapy”.

Dentro de cada trabajo, podemos encontrar las siguientes peculiaridades:

• En el caso de que haya una tabla con una lista de acrónimos, NVCR no quiere que reorganicemos la tabla alfabéticamente: se debe respetar el orden del original.
• Además, si vemos alguna imagen no editable, preguntaremos si ellos la tienen editable y nos la podrían enviar. Si no las haremos «lo más editables posible» con el proveedor habitual de OCR.
• Para las back-translations, siempre añadiremos la palabra «Back-translation» en las portadas, al principio, en Arial, negrita, tamaño 16 y azul por defecto, tal que así:

• Es probable que encontremos erratas o cualquier otro tipo de errores en el archivo source en inglés. Tanto si se identifican a nivel interno o son los propios traductores los que avisan de ello, es conveniente crear un documento online compartido en Drive para poder ir anotando estos errores o cuestiones problemáticas, para que todos los idiomas se revisen y se unifiquen de la misma manera.

Para avisar al cliente de este tipo de errores, a la hora de entregar el proyecto, se les enviará el archivo source original en inglés con los comentarios que sea necesarios añadir.

Durante la gestión de los proyectos, en los Excel compartidos entre las PM para registrar las observaciones relevantes (que normalmente se comunicarán al cliente), es importante redactar directamente los comentarios en inglés y exactamente tal cual se los indicaríamos al cliente. De este modo, la persona encargada de preparar el trabajo de RA solo tendrá que copiar y pegar esos comentarios en el archivo source que se enviará con la entrega.

5.3 Adaptaciones

El 07/11/2023 confirman que adaptar para RA no es una adaptación al uso. Cuando adaptemos, ellos solamente buscan lo siguiente, incluyendo cambios específicos hacia EN-GB:

• Spelling changes: tumor/tumour, -ize/-ise, traveling/travelling, etc.
• Lexical changes (words that have the same meaning but are more commonly used in GB): pointer finger/ index finger, outlet/socket, etc.
• Regarding capitalization, «ILE/INE/ITE Transducer Arrays» needs to adhere according to the original.
  *Esto solo se aplica aquí; cuando traduzcamos “normal” seguimos con el criterio de tratarlo como nombre propio y usar mayúsculas.
• Following the previous point, we will not change any other capitalized word. We will avoid as much “superficial” changes as we can.
• Change the word «patient» with «participant» for EN-GB files.
• Avoid grammatical changes such as “any residues > any residue” (although it should be singular because residue is uncountable, NVCR wants it to stay wrong).
• Avoid rephrasing: for example, do not replace pairs like “rarely/in rare cases, in case/in the event”, etc.
• Do not change the word order if it is not essential: for example, do not apply a change such as:
  Original: Do not enter an MR/MRI environment with the NovoTTF-200T treatment kit.
  vs
  Do not enter with the NovoTTF-200T treatment kit to MR/MRI environment.

The client does not want to improve the fluency of the document, they only want to change some specific terms (subject vs participant, tumor vs tumour) and reduce the amount of modifications to the minimum possible.

NOTA: El texto anterior ha sido escrito en inglés para poder usarlo como plantilla de instrucciones al traductor. Recuerda eliminar los puntos que no sean relevantes si hubiere.

5.4 Trabajos con track-changes

Debemos tener en cuenta que traducir documentos largos con muchos cambios (tanto forward como back-translations) es un trabajo que nos lleva mucho tiempo revisar a nivel interno. Por otro lado, otro de los grandes problemas es asegurarnos de que los traductores usan bien la terminología y siguen las pautas de la guía de estilo e instrucciones.

Por todo ello, y para intentar minimizar el riesgo de errores y el tiempo de revisión por parte de la PM encargada, se plantean las siguientes opciones:

• Para idiomas problemáticos (por ejemplo, coreano, ruso, tamil, árabe…), aunque NVCR no lo pida y siempre que el plazo de entrega lo permita, puede contratarse una revisión por un segundo lingüista que pueda encargarse de comprobar que la terminología es correcta y que se siguen las instrucciones de la guía de estilo.
• Cuando el formato sea muy difícil de manejar y arreglar (ya que muchos de los traductores no se preocuparán en entregar sus traducciones con TC arregladas), conviene externalizar la revisión y arreglo del formato; tanto para las forward translations como para las back-translation. De este modo, la PM encargada solo tendrá que hacer una revisión del formato menos exhaustiva y más llevadera.

Escoger cualquiera de estas opciones de gestión no es obligatorio y la decisión de gestionarlo de una manera u otra quedará en manos de la PM encargada.

5.4.1 Presupuesto al cliente

• En la fase de preparación de presupuesto se actualizará el índice (el campo automático) de los diferentes archivos target para ver si falla o no, aunque no estén como TC. De este modo, en caso de que falle se presupuestará de forma similar a como se realiza con PSI en trabajos de TC con índices.
• En todos los trabajos de TC se contabilizarán 2’/página (totales del documento), que se sumarán a la partida «Hour(s) translation» estándar, para englobar lo siguiente: chequeo de formato, referencias, índice, terminología, etc. Habrá que aplicar cierto sentido común en trabajos donde haya muchas páginas pero tan solo 1, 2, 3 frases que cambian ya que, si no, será difícil justificar ese tiempo.
• Al enviar presupuestos de TC es importante indicar al cliente qué cubre el presupuesto, en qué nos hemos basado. Ver apartado 8 del PM001.

5.4.2 Entregas al cliente

Se arreglarán los índices aunque no estén como TC (el campo automático de los diferentes target).

En lo que respecta a ordenar alfabéticamente siglas/abreviaturas, esto NO se hará con este cliente.

En trabajos de TC es habitual que surjan cuestiones importantes que indicar al cliente y que afectan a los diferentes idiomas involucrados.

Durante la gestión de los proyectos, en los Excel compartidos entre las PM para registrar las observaciones relevantes (que normalmente se comunicarán al cliente), es importante redactar directamente los comentarios en inglés y exactamente tal cual se los indicaríamos al cliente. De este modo, la persona encargada de preparar el trabajo de RA solo tendrá que copiar y pegar esos comentarios en el archivo source que se enviará con la entrega.

En la preparación de la entrega al cliente, como se indicaba, realizaremos los comentarios pertinentes en inglés dentro del documento source. Esto se hará precisamente para evitar que el cliente pregunte por ciertas cosas en la reconciliación cuando estas ya están arregladas en target. Evitaremos, en la medida de lo posible, comentar cuestiones Out of Scope, a menos que sea realmente imprescindible.

5.4.3 QA para trabajos con track-changes

Nos fijaremos en verificar que los cambios están bien incorporados (a nivel formal) y en que la guía de estilo y terminología importante se ha seguido. Puesto que es altamente complicado verificar en detalle si en los trabajos de TC se ha usado la terminología clave del cliente (ej. transducer arrays bien traducido, etc.) es importante fijarse en los términos más clave donde el cliente suele incidir.

En cuanto a las referencias cruzadas y los mensajes “Error not found”, solo se revisarán aquellos que estén “Into Scope”. Es decir, no se revisarán las referencias cruzadas ni los “Error not found” que estén fuera del alcance (“Out of Scope”). Esta revisión se realizará por muestreo. Si el muestreo no presenta errores, se considerará que el resto está correcto. En cambio, si el muestreo presenta errores, será necesario revisarlos todos y corregirlos donde corresponda (siempre dentro de nuestro “scope”).

5.5 Footers

A veces nos pedirán explícitamente traducir la información del pie de página o incluso nos darán instrucciones específicas de cómo hacerlo, pero otras veces no nos dirán nada. Igualmente, nosotros adaptaremos y traduciremos lo que sea necesario.

En general, los pies de página de sus documentos incluyen la palabra «Master», pero nosotros debemos eliminarlo de nuestras traducciones, ya que solamente la versión original es la máster.

Además, las versiones de sus documentos Master siempre serán 1, 2, 3… mientras que las traducciones que entreguemos siempre serán 1.0, 2.0, 3.0… Debemos tenerlo en cuenta en todos los idiomas y ajustarlo en cada traducción.

Por último, debemos recordar añadir el código BT en las back-translations.

Ejemplo de pie de página en el original (EN), CS y su correspondiente BT:

Doc original:            PUM-SD-637 CS EF-33 Optune® UM Master Version 2

Traduc. en checo:   PUM-SD-637 CS EF-33 Optune® UM Version 2.0

                                      PUM-SD-637 CS EF-33 Optune® UM verze 2.0 (si pidiesen traducir la palabra «versión»)

Back-translation:   PUM-SD-637 CS EF-33 Optune® UM Version 2.0 BT

Todo lo anterior también aplicaría en el caso de que exista portada en nuestro documento. Por ejemplo:

5.6 Certificados de traducción

Crearemos un certificado de traducción por documento. En este caso, los contactos de RA nos enviarán los nombres que quieren que usemos en su Request Form. Utilizaremos esos nombres para los archivos resultantes y también en el certificado, tanto «dentro» como «fuera», añadiendo _CoT al final.

Original en inglés:                     QSD-EUUM-005 IL(EN) Rev 01.1 Optune UM w flex.docx

Traducción en hebreo:            QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex.docx

Back-translation del hebreo: QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex BT.docx

Certificados:                                QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex_CoT.pdf

QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex BT_CoT.pdf

Además, si es un trabajo de cambios marcados, no olvidemos mandar ambas versiones: una con los cambios visibles (TC) y la otra ya limpia *:

Original en inglés:                  QSD-EUUM-005 IL(EN) Rev 01.1 Optune UM w flex_TC.docx

Versión inicial en hebreo:   QSD-EUUM-005 HE Optune UM w flex Ver01.docx

Traducción en hebreo:         QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex_TC.docx

QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex.docx

Certificado:                               QSD-EUUM-005 IL(HE) Rev 01.1 Optune UM w flex_CoT.pdf

*En las versiones limpias, no habrá ni TC marcados ni comentarios. Además, no se añadirá un “_clean” en los filenames. Todos los comentarios que haya que dejar al cliente, se marcarán solamente en la versión con TC.

• Creación de certificados para Regulatory Affairs (RA) en el CRM

Con el CRM y el uso de etiquetas se agilizará el proceso de creación de certificados, especialmente cuando son proyectos multilingües.

Entraremos en el CRM > Certificados de traducción > Crear Certificado de traducción. Rellenaremos la casilla Order con el código correspondiente y utilizaremos como cliente a NVCRRA.

El siguiente interrogante informativo nos mostrará las etiquetas que tenemos disponibles:

• {{IDIOMA_DESTINO}}:Se sustituirá por el código (y variantes si las tiene) de idioma de destino elegido.

Es decir, en el caso del portugués de Portugal, escribirá ambos “PT_PT” y “PT_BR”.

• {{NOMBRE_IDIOMA}}: Se sustituirá por el nombre de idioma de destino elegido.

En otras palabras, en lugar de escribir “PT”, escribirá “Portuguese” en el nombre del certificado.

• {{CODIGO_IDIOMA}}: Se sustituirá por el código de idioma de destino elegido.

Volviendo al primer ejemplo, en el caso de portugués no se especificaría variante: solamente escribiría “PT”.

• {{CODIGO_VARIANTE}}: Se sustituirá por el código de variante (si la tiene) del idioma de destino elegido.

En este caso, escribirá el código de la variante del idioma de destino que hayamos elegido en el desplegable un poco más arriba. En el caso del portugués escribirá “pt” o “br”.

OJO: Es importante recordar que siempre hay que copiar e incluir los pares de corchetes para que funcione la etiqueta.

Ahora basaremos la explicación en un par de ejemplos.

Ejemplo 1: idiomas sin variantes potenciales

Lista de nombres para certificados enviados por el cliente:

PUM-SD-666 CS EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 CS EF-50 NovoTTF-200T UM version 1.0 BT

PUM-SD-666 DE EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 DE EF-50 NovoTTF-200T UM version 1.0 BT

En este caso, necesitaremos generar 4 certificados en total: una para la traducción directa y otra para la inversa en checo y alemán. Como se aprecia en las negritas, el texto base es el mismo y solo varían los idiomas implicados y si es una back-translation o no.

Para poder generar todos los certificados de golpe (4 en total), en el CRM continuaremos rellenando la información de la siguiente manera:

1. Escribimos el nombre de la order.
2. Escogemos como cliente a NVCR RA.
3. Escogemos el idioma origen. Normalmente será English (incluso si han pedido BT).
4. Escogemos todos los idiomas target que necesitamos.

En nuestro ejemplo serán dos: Czech y German.

5. En la Descripción, escribiremos una sola línea, que servirá como base jugando con las etiquetas, para generar todos los certificados de una sola vez.

Para seguir con nuestro ejemplo, como hemos hablado, los únicos elementos que cambian son los idiomas. Por lo tanto, utilizaremos la etiqueta {{IDIOMA_DESTINO}} tal que así:

PUM-SD-666 {{IDIOMA_DESTINO}} EF-50 NovoTTF-200T UM version 1.0

6. Si fuese un trabajo de cambios marcados, activaremos la casilla correspondiente. Esto incluirá la frase correspondiente en el certificado (incluido el de la BT si hubiere)
7. Si pidieron back-translation, marcaremos la casilla correspondiente. Esto generará un documento a la par del de la traducción directa que añadirá “ BT” [incluyendo el espacio] al nombre del certificado. Además, en la combinación de idiomas se añadirá el paréntesis “(Back-translation)”.

En nuestro ejemplo lo activaremos.

8. Escogeremos el título del estudio que corresponda, o dejaremos “-“ si no perteneciese a ninguno en concreto.

En este caso, escogeremos “EF-50”.

9. Elegiremos la fecha del certificado.

Al seguir todos estos pasos, este será el resultado generado:

Ejemplo 2: combinación de idiomas sin variante y que pueden tener variante

Lista de nombres para certificados enviados por el cliente:

PUM-SD-666 CS EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 CS EF-50 NovoTTF-200T UM version 1.0 BT

PUM-SD-666 PT EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 PT EF-50 NovoTTF-200T UM version 1.0 BT

Como en el caso anterior, necesitaremos generar 4 certificados en total: una para la traducción directa y otra para la inversa en checo y portugués. Como se aprecia en las negritas, el texto base es el mismo y solo varían los idiomas implicados y si es una back-translation o no. Sin embargo, hay algo que debemos tener en cuenta al generar el certificado: en checo no hay variantes posibles, pero en portugués sí: Portugal o Brasil.

Siguiendo el ejemplo, esto implica que, en la Descripción, no podemos usar la etiqueta {{IDIOMA_DESTINO}} como en el anterior ejemplo, porque el resultado es el siguiente:

La etiqueta {{IDIOMA_DESTINO}} incluirá las variantes y, como en portugués son varias, el resultado no es el deseado.

En este caso, tendríamos que usar la etiqueta {{CODIGO_IDIOMA}} para la descripción:

PUM-SD-666 {{CODIGO_IDIOMA}} EF-50 NovoTTF-200T UM version 1.0

Al hacer esto, se ignoran las variantes y el resultado es el siguiente:

Ejemplo 3: aparición de paréntesis u otros símbolos entre medias en los nombres de certificado

Lista de nombres para certificados enviados por el cliente:

PUM-SD-666 NL(NL) EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 NL(NL) EF-50 NovoTTF-200T UM version 1.0 BT

PUM-SD-666 NL(BE) EF-50 NovoTTF-200T UM version 1.0

PUM-SD-666 NL(BE) EF-50 NovoTTF-200T UM version 1.0 BT

Una vez más, necesitaremos generar 4 certificados en total: una para la traducción directa y otra para la inversa en neerlandés y flamenco. Como se aprecia en las negritas, el texto base es el mismo y solo varían los idiomas implicados y si es una back-translation o no. Sin embargo, hay algo que debemos tener en cuenta al generar el certificado: el idioma y la variante está separado por paréntesis.

Esto implica que, en la Descripción, debemos respetar la estructura del nombre e incluir dichos paréntesis: es decir, escribiremos tantos los paréntesis como los corchetes correspondientes a las etiquetas.

Además, en este caso, se hará uso de dos etiquetas a la vez, que son {{CODIGO_IDIOMA}} y {{CODIGO_VARIANTE}}

PUM-SD-666 {{CODIGO_IDIOMA}}({{CODIGO_VARIANTE}}) EF-50 NovoTTF-200T UM version 1.0

Es importante destacar que hemos mantenido los paréntesis de la estructura que nos proporciona el cliente. Este es el resultado:

Ejemplo 4: uso del nombre de idioma

Lista de nombres para certificados enviados por el cliente:

PUM-SD-666 NL EF-50 NovoTTF-200T UM version 1.0 Dutch

PUM-SD-666 NL EF-50 NovoTTF-200T UM version 1.0 Dutch BT

PUM-SD-666 NL-BE EF-50 NovoTTF-200T UM version 1.0 Flemish

PUM-SD-666 NL-BE EF-50 NovoTTF-200T UM version 1.0 Flemish BT

Una vez más, necesitaremos generar 4 certificados en total: una para la traducción directa y otra para la inversa en neerlandés y flamenco. Como se aprecia en las negritas, el texto base es el mismo, en flamenco especifican variante y varía si es una back-translation o no. Sin embargo, en este caso en particular el cliente ha decidido escribir el nombre del idioma al final.

Una posible solución en este caso sería, en la Descripción, utilizar dos etiquetas: {{IDIOMA_DESTINO}} y {{NOMBRE_IDIOMA}}, tal que así, aunque veremos un problema a continuación

PUM-SD-666 {{IDIOMA_DESTINO}} EF-50 NovoTTF-200T UM version 1.0 {{NOMBRE_IDIOMA}}

En el sistema, el idioma flamenco siempre aparece como “Dutch (Belgium) / Flemish”, por lo que en este caso no nos quedaría más remedio que hacer los certificados por separado, de forma tradicional, siendo las etiquetas inservibles.

5.7 Entregas

Para guardar los archivos, creamos una carpeta en final con el código del idioma en mayúsculas (DE, FR-ca, HU, etc.) y dentro incluimos tanto la traducción directa como la back-translation juntas con sus correspondientes certificados.

Los trabajos los devolveremos siempre en los hilos correspondientes vía Gmail, manteniendo a todos los contactos ya presentes en copia (incluyendo a nuestra cuenta de email específica para este cliente).

Si el trabajo pesa demasiado, haremos un zip con la entrega que se generará en la misma altura que las carpetas de cada idioma. Seguiremos, por ejemplo, el siguiente esquema de nombre:

Delivery dd-mm-yy [códigos de idioma + FT/BT si alguno está dividido]

Delivery 24-Mar-23 ES, HU (FTs + BTs)

Compartiremos el link de descarga que generará Plunet. No borraremos los zip de entregas anteriores, ya que así archivaremos todas las versiones que hemos enviado al cliente.

5.8 Reconciliation of changes

Para trabajos de este departamento, tras la entrega de las traducciones y back-translations el cliente hará una revisión de la back-translation comparándola con la versión original en inglés. Una vez lo hagan, nos devolverán las back-translation con comentarios acerca de lo que quieren que revisemos y comprobemos. Ante todo, es importante tener claro que lo que al cliente le interesa es comprobar que lo que nos están comentando está bien traducido en la Forward Translation del idioma que corresponda; en muchos casos pueden existir cambios que se requieran hacer en la Back-translation pero que no afecten a la Forward Translation.

Para saber cómo gestionar la recepción de este tipo de feedback por parte de NVCR, es importante seguir los pasos de “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”.

Una vez entreguemos los materiales actualizados al cliente, guardaremos y actualizaremos los documentos:

• Guardamos los documentos en la carpeta “Documentos enviados por el cliente- Revisados-20240517” (donde 20240517 es la fecha en la que entregamos los archivos revisados y actualizados al cliente) que crearemos dentro de la carpeta “Final” del pedido y en la carpeta del idioma que corresponda donde están los documentos que entregamos en su momento.
• Si no fue un trabajo de track changes, buscamos los sdlxliff (carpeta “toUpdate” o “aa_actualizados), los actualizamos* con los cambios que se les hayan realizado a los documentos y los volvemos a subir a “toUpdate” para que se incluyan en la TM.
• Añadimos la información en el Memo del Pedido. Así sabremos que ya se ha realizado una revisión de comentarios del cliente de los documentos y en qué fecha. Por ejemplo: Documentos enviados por el cliente con sus comentarios para nuestra correspondiente revisión en FWT y en BT:
  • ES (09/05/2024)
  • CS (27/05/2024)
  • PL (28/05/2024)
  • KO (29/05/2024)

* Los cambios que se realicen en la BT tras cambios realizados en la FWT no se deben incluir en los sdlxliff ya que los segmentos están traducidos conforme los segmentos originales. Sólo se deben incluir los cambios realizados en la BT por errores de traducción en la BT.

5.9 Reparto de los trabajos para el departamento de Regulatory Affairs (RA)

El trabajo para este departamento es compartido por todas las PM de Okodia, sin excepciones.

Se pone a disposición de todas un Excel de seguimiento: “REPARTO TRABAJOS REGULATORY AFFAIRS”.

En ese Excel, cada persona encargada deberá rellenar los datos correspondientes de la pestaña «Trabajos». Es importante hacerlo de modo similar a como están los actuales para que los cálculos de la pestaña «Recuentos personas» funcionen bien.

Solo la gestora que se encargue del proyecto deberá marcar la columna E del Excel de reparto y anotar el número total de idiomas que gestione del proyecto en la columna F para que se le añada ese tiempo de gestión (15 minutos por presupuesto y 5 minutos por cada idioma por el tiempo mínimo que conlleva analizar los documentos, añadir el SDLXLIFF y el report o calcular el tiempo de TCs) a su recuento de esfuerzo en horas.

La pestaña «Recuentos personas» tiene el recuento de trabajos que ha realizado cada persona.

• 1) Los emails de NVCR RA los recibirá todo PM. En caso de que el cliente no lo envíe a la dirección de email destinada para ello y lo reciba otro equipo, ese email se redirigirá a todo PM.

• 2) Cuando NVCR RA envíe una solicitud, se encargará la persona que menos trabajos lleve en ese recuento de la pestaña «Recuentos personas». En caso de empate, el desempate se realizará por orden alfabético del nombre que aparece (de la A a la Z).

• 3) Esa persona será la que se encargue de preparar el presupuesto y enviarlo al cliente.

• • 3a) En caso de que el presupuesto sea de 1 único idioma, esa misma persona será la que se encargue de gestionarlo una vez aprobado por el cliente.
  • 3b) En caso de que el presupuesto sea a más de 1 idioma, esa misma persona será la que se encargue de repartir el trabajo entre ella misma y el resto de compañeras, como más oportuno considere, teniendo en cuenta las personas que menos recuento llevan (y en caso de empate el orden alfabético).
  • 3c) Es imposible prever aquí todas las diferentes posibilidades, de cantidad de idiomas, de recuentos, etc., por lo que se considera que para el 3b se utilizará el sentido común y la forma más apropiada. Por ejemplo, podría darse el caso de que haya algún trabajo de 200 palabras a 5 idiomas donde la persona encargada considere que es mejor que lo realice 1 única persona (en ese caso ella misma, lógicamente).
  • 3d) Sea como fuere, cada idioma tiene el mismo peso, independientemente de su volumen o de si el trabajo incluye 1 o más documentos a traducir. Es decir, a efectos de recuento, contará lo mismo 1 idioma de 10.000 palabras que 1 idioma de 200 palabras, o que 1 idioma con 2 documentos. FT y BT funcionan como 1 pack.
  • 3e) En el caso del presupuesto, debe anotarse en el Excel. En caso de que el cliente no apruebe, quedará registrado con el código de presupuesto. En caso de que el cliente apruebe (que es lo habitual), se modificará el código de presupuesto por el código de order.

• 4) En el proceso de gestión, la persona encargada será quien centralizará las posibles preguntas/dudas que las otras personas le hagan llegar para consulta con el cliente. Evitemos que el cliente tenga que recibir emails de 10 personas diferentes con cada trabajo.

• 5) Para la devolución del trabajo al cliente, la persona encargada será quien devolverá la Order al completo (solo la devolución, es decir, el resto de PMs se encargarán de gestionar y preparar la entrega de su idioma). Ídem, evitemos que el cliente tenga que recibir emails de 10 personas diferentes con las entregas.

• 6) En el caso de Reconciliation of Changes, se encargará la persona que gestionó el idioma afectado, pero esto NO se anotará en el Excel.

• 7) En caso de ausencia de la persona a la que le toque, se encargará la siguiente persona con menor número del recuento u orden alfabético (en caso de empate).

• 8) Para los trabajos «en proceso» o de un Reconciliation of changes, en caso de ausencia de la persona que se tendría que ocupar, será la coordinadora del equipo natural de dicha persona quien se encargará de decidir quién se encarga de suplirla.  Por supuesto, si tampoco está la coordinadora, el resto del equipo debería repartirlo igualmente, de modo similar a como se realiza con cualquier otro trabajo en caso de vacaciones.

6. Proyectos para el departamento de Marketing y DSS Operations

Los trabajos para el departamento de DSS Operations son traducciones de los panfletos informativos que los pacientes de NVCR reciben cuando les llega todo el material para el inicio de sus terapias (Guidebook, Travel Letter, etc), por lo que es un departamento que enviará pocos trabajos, ya que sus materiales apenas se actualizan.

Los trabajos de Marketing son variados y pueden involucrar contenido web, brochures, pero también panfletos o presentaciones para médicos; es decir, no tiene por qué ir siempre dirigido al paciente. Además, pueden trabajar desde el alemán, no solo desde el inglés.

Pueden enviar Words, PPTX, IDMLs… Si envían un PDF solamente, podemos preguntarles si tendrían la versión editable por un casual. Además, hay veces que necesitan DTP (no siempre), así que es conveniente consultarlo con ellos.

• En este caso los trabajos pueden venir desde Suiza (NVCR GmbH), Alemania (NVCR GmbH (Germany)), Austria (NVCR Austria GmbH), Italia (NVCR Italy S.R.L.), España (NVCR Spain S.L), Reino Unido (NVCR UK Limited) o Estados Unidos (NVCR Inc.). Cada país tiene sus propias posibilidades en cuanto a POs, así que, para más información, consultar el punto 3.

6.1 Materiales

Memorias de traducción*:	NVCR_Marketing	Terminología:	NVCR_Marketing
*En caso de ser una combinación poco común, probaríamos a usar la TM medical (si existiese) a ver si es útil.

Es importante que los traductores usen la terminología específica de Marketing, ya que para este departamento no se deben traducir los términos clave: «Tumor Treating Fields», «Transducer Arrays», «TTFields», « Array» (y todas sus posibles variantes).

Estamos creando las TMs de este departamento desde cero así que, si no son muy útiles de primeras, se puede probar con la genérica de NVCR, por si ésta aportase algo más.

6.2 Documentos dirigidos a profesionales

En principio los documentos que estén dirigidos a personal médico no necesitan revisión por parte de un segundo traductor. De todas maneras, si no lo tenemos claro, siempre podemos matizarlo en el correo al cliente por si, efectivamente, necesitasen esta segunda revisión.

6.3 Documentos dirigidos al paciente

Este departamento no tiene una forma de trabajo estipulada, así que conviene siempre asegurarnos con el cliente lo siguiente:

• ¿Será un trabajo solo TRA?
• ¿Necesitan T+R?

Debemos recordar que si necesitan traducción y revisión (T+R) añadiremos el tiempo de revisión en horas.

6.4 Certificados de traducción

Crearemos un certificado por documento. Además, utilizaremos el nombre del archivo original «dentro», pero al nombre de archivo «fuera» le modificaremos su código de idioma al de la traducción y añadiremos «_CoT» al final del certificado. Ejemplo:

Original en hebreo:         EF-32_14-503_Internal Audit Report_final_24Jan2023_HE.docx

Traducción en inglés:      EF-32_14-503_Internal Audit Report_final_24Jan2023_EN.docx

Certificado:                        EF-32_14-503_Internal Audit Report_final_24Jan2023_EN_CoT.pdf

Además, si el trabajo fuese de cambios marcados, actualizaríamos la información que aparece en el nombre de archivo, tales como la versión y la fecha, y devolveríamos tanto la versión con cambios (TC) como la limpia *:

Original en inglés:                  EF-28_EN_ICF_Germany_v.9.0_23Sep2022_TC.docx

Versión inicial en alemán:   EF-28_DE_ICF_Germany_v.8.0_28Apr2022_TC.docx

Traducción en alemán:         EF-28_DE_ICF_Germany_v.9.0_23Sep2022_TC.docx

EF-28_DE_ICF_Germany_v.9.0_23Sep2022.docx

Certificado:                               EF-28_DE_ICF_Germany_v.9.0_23Sep2022_TC_CoT.pdf

*En las versiones limpias, no habrá ni TC marcados ni comentarios. Además, no se añadirá un “_clean” en los filenames. Todos los comentarios que haya que dejar al cliente, se marcarán solamente en la versión con TC.

6.5 Entregas

Normalmente las haremos vía Plunet. Sin embargo, si el hilo fuese muy enrevesado y se prefiere, se puede valorar devolverlo vía Gmail sin mayor problema manteniendo siempre en copia a nuestra cuenta de correo para este cliente.