Cómo gestionar un Summary of Changes (SoC)

Descripción

Cómo gestionar un Summary of Changes (SOC)

• Dirigido a: PMM
• Duración estimada: 1h 30min

1. Introducción: Qué es un SoC

Los Summary of Changes (SoC) son documentos redactados para recopilar y explicar los cambios que se han hecho entre una versión y otra en determinados documentos de los estudios clínicos, como ICFs, protocolos o manuales de investigador (IBs). La traducción de un SoC no es un trabajo de track changes (sino que se traducen desde cero) pero su contenido recoge los track changes que se han realizado en ese otro documento relacionado, de manera fiel, con idéntica redacción.

Generalmente, inician con un texto donde precisamente se explica la finalidad del SoC y el formato en que se encontrarán descritos los cambios, pero la mayor parte del documento está formada por la tabla donde se describen los cambios. En ella puede haber diferentes columnas dependiendo del SoC, por ejemplo, en la que se indica en qué sección se encuentra el fragmento, cómo era ese fragmento antes de cambio, el fragmento con los cambios implementados, y el motivo de los cambios. Las dos columnas fundamentales son las que reflejan el texto antes y después de los cambios y son las que explicaremos a continuación.

Recordemos que no es un documento con track changes como tal, sino que los “replica”, mediante un determinado formato (en cada SoC puede cambiar, pero habitualmente es del siguiente modo): las adiciones, subrayadas; las eliminaciones, tachadas; y puede haber cursivas y negritas. Este podría ser un ejemplo de la tabla dentro de un SoC:

Si vamos al documento en cuestión donde se realizaron esos cambios, vemos cómo aparece el cambio nº 1 de la captura anterior:

El cliente suele enviar el archivo de referencia que tiene los cambios marcados, del cual hay que copiar la traducción, porque el contenido de los cambios se debe traducir igual en el SoC que en el documento de referencia. En caso de que no lo envíe, tendremos que pedírselo o bien buscarlo nosotros en nuestros archivos, pero confirmar con el cliente si es el que debemos utilizar como referencia.

El proyecto, aunque es particular, se cobra como un trabajo normal, puesto que no es un trabajo de revisión como tal, pero tampoco es un “copia y pega” al uso por estos motivos:

• El texto eliminado en los SoC no es realmente texto eliminado, sino un texto traducido y con formato de tachado. Esos mismos textos eliminados, dentro del documento de referencia sí aparecen con track changes reales, así que no se puede copiar directamente de ahí porque está eliminado. Como mucho se puede rechazar el cambio, copiar y pegar en el segmento del SoC y luego tacharlo de nuevo en el documento de referencia.
• El texto añadido tiene que aparecer subrayado. Se podrá copiar directamente del documento de referencia pero habrá que retocar el formato.
• A veces el texto original que pone en el SoC no es exactamente igual que al del documento modificado y habrá que determinar cómo proceder.
• A veces es difícil de encontrar un fragmento dentro del documento con track changes y hay que dedicarle casi más tiempo a esos segmentos que si los estuviéramos traduciendo desde 0.

2. Cómo presupuestar un SoC

Para presupuestar un Summary of Changes (SoC) haremos lo siguiente:

• OPCIONAL

En primer lugar, buscaremos en qué proyecto se tradujeron los track changes del documento de referencia que usaremos para la traducción del SoC (si no lo realizamos nosotros, esta opción no sirve, pasamos a la opción 2). Nos aseguraremos de que el documento de referencia con los track changes que envía el cliente es idéntico al que enviamos nosotros en esa entrega anterior (sería lo esperable). Podemos confirmarlo haciendo una comparación de ambos archivos en Word. Si son idénticos, podemos hacer lo siguiente para analizar el SoC que tenemos que traducir:

1. Del anterior proyecto de TC no tenemos SDLXLIFF (no se hizo en Trados), pero sí lo tendremos de la traducción desde cero que se hiciera previa a esos TC. Buscamos si la traducción desde cero fue justo la inmediatamente anterior al proyecto de TC (si no fue justo la anterior, este enfoque no nos vale, porque si hubo más fases de TC habrá más diferencias de contenido que no tenemos marcadas). Si es el caso, podemos crear una TM que contenga solo el SDLXLIFF de esa traducción, que rescataremos del servidor si aún está disponible *. No usaremos otra TM más que la que creemos. Analizaremos el source con esa TM y haremos el presupuesto con ese report, además de enviarle la TM al traductor y aclararle que solo use esa. De ese modo nos aseguraremos de que las coincidencias 100 % que salgan no proceden de otros proyectos y que en Trados nos saldrá la traducción exacta del documento de referencia, salvo por las partes que salen con track changes, que el traductor tendrá que tomar de la traducción del documento de referencia y ajustar el formato como deba.

*Nota: hay que fijarse bien en si el SoC para traducir está principalmente formado solo por la tabla en la que se detallan los cambios, o si es la tabla con un breve texto antes, o si se trata de la tabla con mucho texto antes o incluso después. Es decir, si hay mucho texto adicional a los propios cambios o no. Habrá que tenerlo en cuenta para decidir si interesa utilizar la TM general/del cliente (para esos textos que no constarán en el documento de referencia) o crear la nueva. En caso de tener bastante texto fuera de las columnas que describen los cambios, quizás conviene separar el documento en dos y utilizar la TM general/del cliente para los textos que no describen los cambios y la TM específica que creemos para la tabla que describe los cambios. Eso sí, si se separa el SoC en distintos extractos, debemos asegurarnos de transmitir al traductor qué parte traducir con qué TM, y en nuestro control de calidad deberemos volver a unir los textos para formar el SoC de destino.

• Si no contamos con el SDLXLIFF de la versión inmediatamente anterior

Si no contamos con el SDLXLIFF de la versión inmediatamente anterior, simplemente utilizaremos la TM general/del cliente, aunque realmente no conviene seguir ese contenido, sino que el traductor deberá copiar y pegar todo el contenido del archivo de referencia, salvo en caso de diferencia de contenido entre lo que estamos traduciendo y lo que indica el documento de referencia, donde, aunque por defecto prima el contenido del original que estamos traduciendo, habría que avisar al cliente para buscar confirmación.

Al enviar el presupuesto, se le confirmará al cliente que realizaremos la traducción del SoC utilizando la traducción del archivo de referencia.

En ocasiones, el cliente pregunta al respecto del presupuesto. Se le debe explicar que, por las características propias del trabajo y el proceso que se sigue debemos contabilizarlo por palabras, como se hace de manera habitual. Se puede ampliar con una explicación similar a esta (hay que fijarse antes en el contexto, no vaya a ser que no aplique del todo y convenga adaptarlo un poco):

Let me explain the amount of work this project implies. Firstly, we need to search every single paragraph to ensure the text is exactly the same, which takes longer than it may look. After having found the information, we can’t copy and paste it directly due to the formatting.

If we copy/paste the text that is deleted in the source file, whereas it is not deleted (but strikethrough) in the target version, which means that we need to add it manually later, after copying/pasting, plus fixing the formatting (bold, underline, strikethrough, etc.). The same happens with all the rest of the text, with more or less deleted (actually not deleted) text and formatted text.

In our opinion, copying/pasting plus adding the strikethrough text plus fixing the format takes more or less the same amount of time than translating using our TMs and checking the wording against the source text. That’s why we can’t talk about a copy/paste and that’s why we issued the quote as a normal translation (even if the matches still apply and have been leveraged).

NOTA IMPORTANTE: Si en el SoC para traducir hay imágenes, debemos consultar el siguiente apartado antes de preparar el presupuesto.

3. Imágenes dentro del SoC

Puede que en algunos SoC para traducir veamos imágenes no editables. En un proyecto de traducción habitual, las editaríamos para poder traducir su contenido o extraeríamos el contenido, lo copiaríamos en una tabla para enviarlo a traducir y posteriormente maquetaríamos la imagen en idioma de destino. En este caso, no es necesario. Recordemos que el SoC es un documento en el que aparecen redactados los cambios marcados que se han hecho en el documento de referencia. Las imágenes en el SoC corresponderán a gráficos, a tablas o a algún elemento similar que aparecerá con cambios marcados dentro de la traducción de referencia. Es decir, podemos extraer el texto para las imágenes de la traducción que usaremos como referencia. Simplificando, la gestora de proyectos hará capturas de pantalla de la traducción de referencia para pegar esas imágenes traducidas en nuestra traducción del SoC. Normalmente será una tarea para la que no hará falta esperar al paso de verificación. Se puede ir realizando durante el transcurso del proyecto y ya dejar las imágenes traducidas listas para pegarlas cuando se tenga la traducción del SoC.

• Formato de las imágenes y presupuesto

El primer paso al ver que hay imágenes en el SoC que tenemos que traducir es acudir a la traducción de referencia y confirmar que esas partes efectivamente aparecen y ver cómo aparecen.

Podría ocurrir que el formato de los cambios en las imágenes del SoC no coincida con el formato de los mismos en la traducción.

En la imagen anterior vemos (a la izquierda) que, en el SoC, habrá que traducir 3 imágenes: la tabla previa (fondo blanco), la tabla previa tachada entera (fondo rojo) y la tabla nueva añadida entera (fondo azul), mientras que en la traducción que usaremos como referencia (a la derecha) los cambios no se hicieron del mismo modo. No se tachó la tabla entera y se añadió la nueva, es decir, no lo tenemos disponible de ese modo para poder hacer capturas y pegarlas en la traducción. En cambio, vemos en la traducción de referencia que la tabla previa se modificó con los cambios que había que implementar, uno a uno. ¿Podremos copiar las tablas tal cual las tenemos traducidas o qué pasa con esa diferencia de formato? Es algo que debemos consultar al cliente antes de preparar el presupuesto, exponiéndole lo que ocurre.

Vamos a partir de que el contenido de las imágenes sí sea igual (al final de este apartado hablaremos sobre diferencias de contenido) y a centrarnos solo en las posibles diferencias de formato. Tenemos las siguientes indicaciones del cliente PSI respecto a cada caso (para otros clientes, consultar sus preferencias):

1. Si en el SoC original aparecen los TC de las imágenes exactamente como en la traducción de referencia, no habrá que hacer nada complejo ni consultar nada al cliente. Bastará con hacer capturas de pantalla de la traducción de referencia y copiarlas como imagen dentro de la traducción del SoC que entregaremos.
2. Si el formato/la disposición en que aparecen los TC en las imágenes del SoC es distinto al de la traducción de referencia, antes de realizar el presupuesto debemos exponerle al cliente lo que ocurre y pedirles su autorización para preparar las imágenes traducidas para el SoC haciendo capturas de pantalla de los TC tal y como aparecen en la traducción de referencia. Les podemos explicar también que, si tenemos que replicar el formato de los TC de las imágenes del SoC original, esto implicaría rehacer los cambios de esas partes dentro de la traducción, siguiendo un proceso muy manual y poco productivo, muy difícil de replicar por un traductor humano – y esto solo por motivos de formato.

Lo esperable en estos casos es que acepten que el formato no coincida. De todos modos, se acordó lo siguiente. De manera habitual, en todo trabajo de track changes debemos implementar los TC con el mismo formato que aparezcan en el original, por lo que si cumplimos eso, no será esperable que la traducción de referencia muestre un formato distinto. Sin embargo, si en el contexto de ese trabajo previo de track changes (cuando se actualizó el documento de referencia) ya encontramos tablas conflictivas, en ese momento debimos consultarles si podíamos “simplificar” el proceso tachando la tabla entera y añadiendo la nueva.

Si entonces dijeron que sí, van a aceptar el mismo enfoque para la traducción de las imágenes en el SoC, así que se pueden sacar las capturas de la traducción de referencia tal y como salen. (No quita que debamos consultarles o/y recordarles esto que se acordó).

Si dijeron que no, el trabajo costoso de implementar los track changes siendo fieles al formato original ya debimos hacerlo en su momento, así que el formato de los TC en la traducción coincidirá con el del SoC original. Tendremos las tablas como las necesitamos para las capturas.

De cualquier modo, si el formato de las imágenes en el SoC y en la traducción de referencia no coinciden, hay que consultar al cliente antes de preparar el presupuesto, así que si encontramos el hilo del proyecto en el que actualizamos el documento de referencia, se puede ver qué se decidió entonces en este aspecto y mencionárselo cuando les pidamos confirmación por las imágenes del SoC.

No se presupuesta nada adicional por la preparación de todas las imágenes que se puedan obtener haciendo capturas del texto de la traducción tal y como lo tenemos.

Si hubiera que retocar manualmente los TC para alguna imagen porque el formato no coincida y el cliente insista en que debemos mantener el formato del SoC original, sí facturaremos el tiempo que calculemos que vamos a tardar, en una partida de Hour(s) DTP. Se puede hacer una estimación o se puede adelantar la preparación de una imagen y multiplicar ese tiempo por el total de imágenes similares que habrá que preparar. Recordemos también añadir al plazo algún día adicional para preparar las imágenes. Puesto que es una tarea muy costosa, el cliente entiende que es fácil no acertar con la estimación inicial, así que están abiertos a que enviemos el presupuesto actualizado una vez entreguemos el trabajo. Seamos generosos en el cálculo de tiempo y en el plazo, porque el proceso puede ser complejo.

• Ejemplos de tipos de imágenes y cómo obtenerlas de la traducción de referencia

En los ejemplos, veremos un SoC original en inglés – a la izquierda en las capturas de pantalla – y su traducción en español – a la derecha en las capturas. Existe también el documento de referencia en inglés (original), pero en principio no se requiere para nada en este proceso. Vamos a mostrar distintos ejemplos de distintos grados de dificultad y explicaremos cómo proceder en cada caso. Nos ayudará a entender en futuros proyectos reales qué habrá que hacer en cada imagen que encontremos para obtener el texto que necesitamos.

Si hubiera que manipular las tablas/gráficos por las diferencias de formato que hemos comentado, el proceso general será el siguiente. Copiaremos cada una de ellas de la traducción de referencia a un Word aparte, donde las dejaremos de todos los modos que vayamos a necesitar (versión previa rechazando los TC, versión con TC, versión nueva en limpio aceptando los TC, etc.) y haremos las modificaciones que necesitemos hacer para replicar el formato del SoC. De ahí haremos las capturas de pantalla y las pegaremos en la traducción del SoC.

IMPORTANTE: Guardemos este/estos Word que preparemos en la carpeta VER/Final (eso sí, evitaremos enviárselos al cliente), ya que pueden ser muy útiles más adelante si tras la revisión del cliente se detecta algún error y hubiera que hacer alguna corrección adicional en alguna de las imágenes.

Cuando se hagan las capturas de pantalla, desmarquemos antes el símbolo del calderón (¶) para que no aparezcan las marcas de formato y recortemos las capturas como sea conveniente para que la imagen resultante sea exactamente equivalente a la del original y muestre solo el texto que hay que mostrar.

Ejemplo 1.

Es el caso más sencillo. En la traducción tenemos el gráfico tal y como lo necesitamos. En el SoC aparece en limpio (sin TC), así que habrá que dejarlo igual. Solo habrá que tomar el gráfico de la traducción, aceptar los TC (si hay alguno) y obtener la captura.

Ahora veamos ejemplos donde el formato no coincide. Al consultar con el cliente procuraremos que den su visto bueno para tomar las capturas de las imágenes tal y como aparecen en la traducción pero, por si no aceptan, en cada ejemplo se explicará el proceso que habría que seguir si hubiera que respetar el formato original necesariamente.

Ejemplo 2.

En el original se sustituye la tabla entera y en la traducción no. Este caso lleva algo de tiempo, pero no es muy difícil. No requiere realizar los cambios manualmente uno a uno sino que a partir de lo que consta en la traducción de referencia, ya tenemos todo lo que necesitamos para la traducción del SoC. Solamente habrá que sacar diferentes versiones de la tabla traducida, rechazando o aceptando cambios. Necesitaríamos sacar 3 imágenes a partir de la tabla que aparece en la traducción:

1. Versión limpia previa a los cambios (fondo blanco): para esto necesitamos una copia de la tabla traducida con los cambios rechazados.
2. Con track changes, versión anterior tachada (fondo rosa): tachamos la tabla que acabamos de preparar.
3. Con track changes, tabla nueva añadida (fondo azul): habrá que copiar la tabla de la traducción al Word aparte, teniendo el control de cambios activado en ambos archivos. Aparecerá la tabla entera añadida.

Ejemplo 3.

En el original se hacen los cambios uno a uno y en la traducción no. Ocurre al contrario que en el ejemplo anterior y esto requiere más trabajo y tiempo, ya que debemos realizar manualmente todos los cambios uno a uno sobre la tabla previa a los TC.

En estos casos, en primer lugar intentemos realizar una comparación automática, por si hubiera suerte de que la imagen quedase exactamente como necesitamos. Comparamos con Word un archivo donde tengamos la tabla previa a los cambios y otro donde tengamos la tabla nueva (ambas en limpio, sin TC). El resultado de las comparaciones de Word es bastante aleatorio, así que podría no servir, pero merece la pena intentarlo. Si el formato es muy similar al del SoC original, podemos hacer manualmente los pocos ajustes que falten. Si el resultado no es nada similar, tendremos que trabajar en toda la tabla manualmente, por ejemplo, como se explica a continuación.

Tendríamos que buscar en la traducción de referencia la tabla previa (que aparecerá tachada), copiarla en limpio en un Word aparte e implementar en ella todos los cambios uno a uno, atendiendo al formato del original. Por ejemplo, en este caso, vemos que en la imagen original hay un par de celdas y un par de números que son texto ya existente que se ha mantenido igual, es decir, que no sale con control de cambios, ni tachado ni añadido (el que tiene color de letra negro). Hay que ir jugando con el control de cambios según vayamos implementando los cambios en la tabla. Si dentro de una tabla añadida con TC necesitamos dejar solo un par de partes aceptadas (que salgan en limpio, como texto previo), podemos seleccionar esas palabras y aceptar el cambio (aplicará solo a la parte seleccionada).

En casos de tablas con una estructura muy compleja de replicar partiendo de la tabla previa a los cambios, en ocasiones será más sencillo crear una tabla desde cero, darle la forma que necesitemos con las funciones del menú Diseño de tabla > Dibujar hasta que quede como la tabla del SoC y rellenar cada celda con el contenido como se requiera.
.

Ejemplo 4.

En este ejemplo vemos de nuevo que aparece texto de la versión previa (color negro) en las notas a pie de tabla, pero no se ve igual en la traducción, donde todas las frases han sido añadidas desde cero. Aunque laborioso, eso es fácil de replicar cuando preparemos la tabla, pegando las frases debajo, una a una, y dejando cada una como corresponda. Sin embargo, las frases que en el original salen tachadas no las vemos en la traducción, pero también las necesitamos (para dejarlas tachadas). Habría que buscarlas dentro de la traducción, en algún lugar próximo en el texto, probablemente debajo de alguna otra tabla cercana. Podría ser de ayuda trabajar con una copia de la traducción con la versión previa a los TC, ya que ubicaremos esas frases más fácilmente.

Además de ir activando y desactivando el control de cambios para pegar cada frase de un modo distinto (añadido, tachado, texto preexistente en versión limpia…), también se puede pegar todo el texto previo a los TC, en bloque, con control de cambios activado (saldrá todo añadido nuevo) y seleccionar frase a frase y aceptar/rechazar cambios para dejar cada frase como corresponda.

En trabajos reales podríamos encontrar tablas más complejas que las de los ejemplos, con frases que no encontremos fácilmente en la traducción, con estructuras que no entendemos cómo replicar. Hay que analizar muy bien cómo salen las tablas, qué necesitamos conseguir/replicar, entender si se han fusionado dos tablas o distintos apartados, buscar si los textos que nos faltan aparecen cerca en la traducción…

Los procesos descritos en los ejemplos anteriores solo son ideas de cómo proceder. Cada gestora podrá manejarse con la función de control de cambios del modo que le resulte más sencillo mientras logre dejar las imágenes idénticas a las del SoC original.

• Diferencias de contenido en las imágenes

No es esperable que el SoC para traducir tenga diferencias de contenido con el documento de referencia (si ocurre, hay que consultar con el cliente cuánto antes cómo proceder) y menos aún que las diferencias afecten justo a las imágenes pero, si ocurre, consultemos para nos indiquen si copiamos tal cual los TC para las imágenes de la traducción de referencia (no coincidirá el contenido 100% con el original) o si debemos traducir exactamente el contenido de las imágenes del SoC original.

Lo más frecuente es que prime el contenido del SoC. Si el cliente pida traducir exactamente el contenido de las imágenes del SoC, cada PM valorará cómo interesa hacer. Si las diferencias son muy pocas, se puede extraer el contenido para las imágenes de la traducción de referencia, la PM lo modificará como convenga (con la ayuda del traductor, si se requiere) y obtendrá la imagen traducida. Si son muchos los cambios de contenido, quizás necesitamos editar la imagen original para, una vez editable el texto, poder traducirlo desde cero (aunque se sugiera al traductor usar como referencia la imagen dentro de la traducción) y posteriormente convertirlo en imagen no editable.

Si tuviéramos que incurrir en gastos de edición de imágenes por este motivo, avisemos al cliente de que tenemos que actualizar el presupuesto emitido para incluir esta tarea.

4. Cómo asignar un SoC

Si el documento para traducir es un PDF y se tiene que enviar a editar, se explicará a la persona encargada de ello que necesitamos que el formato del texto coincida exactamente (que se marquen las palabras tachadas como tachadas y las subrayadas como subrayadas, pero no usando tracked changes, claro).

Al traductor debemos explicarle qué documentos le hemos enviado (hablarle de la traducción de referencia) y pedirle que acceda a la Translator’s Knowledge Base y lea con detenimiento las instrucciones del artículo “Instructions for Summary of Changes (SoC)”, con todo el proceso que debe seguir, y que también incluye instrucciones sobre cómo actuar si detectase diferencias de contenido entre el SoC para traducir y la traducción de referencia.

ATENCIÓN: No es esperable que el SoC no coincida al 100% en contenido con el documento de referencia (nos referimos a las columnas donde se describen los cambios), así que en caso de encontrar diferencias de contenido, el traductor debe avisarnos lo antes posible. Normalmente primará el contenido del SoC, por ser el documento original que estamos traduciendo en este momento; sin embargo, debemos avisar al cliente lo antes posible para que confirme cómo proceder.

Cuando el traductor haya enviado la traducción, haremos una revisión por muestreo (es decir, seleccionaremos partes del documento al azar) incluso si después el archivo va a revisarlo un segundo traductor. En este QA, nos aseguraremos de que la traducción dentro del sdlxliff coincide con el texto de la traducción de referencia. Si no coincide, se lo enviaremos de nuevo al traductor para que lo arregle. Si coincide como debe, se lo pasaremos al revisor con las mismas instrucciones: debe comprobar que la traducción se haya extraído del documento de referencia y también que el formato de los segmentos source y target coincida. Le remitiremos también al enlace específico de la Translator’s Knowledge Base.

5. Cómo revisar un SoC

Haremos una búsqueda por muestreo para confirmar que la traducción de los cambios del SoC coincide con la traducción dentro del texto del documento de referencia y, una vez confirmado, se hará un QA normal.

Nota: Si en cualquier fase del proyecto nosotros o el traductor hemos detectado que el contenido de los cambios dentro del SoC es algo diferente de lo que pone en la traducción del documento de referencia, se pueden seguir dos procedimientos diferentes:

1. Debemos avisar al cliente en cuanto nos demos cuenta y preguntarle cómo proceder. Nota: PSI nos ha indicado en anteriores ocasiones que el SoC original prima, pero en cualquier caso debemos avisarles por si se requiere otro enfoque.
2. En caso de que no sea posible consultar al cliente, le avisaremos sobre esta cuestión en el momento de la entrega, para que puedan valorarlo. Ante la duda de cómo proceder, es aconsejable que predomine el contenido del SoC, ya que es el original que estamos traduciendo,aunque no acabe de coincidir con lo que dice el documento de referencia.