Preguntas frecuentes PM

Como regla general, los traductores tienen un único listado de tarifas, por lo que esta distinción no será necesario realizarla.

Sin embargo, cuando se trata de elegir una tarifa estándar o especializada para un cliente que tiene ambos listados, podemos plantearnos si un texto es estándar/divulgativo o especializado dependiendo del lenguaje utilizado, la audiencia a la que se dirige y el propósito del texto. Aquí se muestran algunas características que pueden ayudarte a distinguir entre estos tipos de textos:

Texto estándar o divulgativo:

1. Lenguaje cotidiano y accesible: Utiliza un lenguaje sencillo y de uso común.
2. Ausencia de términos técnicos: Evita términos especializados y jerga técnica, aunque podría incluir algún término técnico de manera limitada.
3. Dirigido a una audiencia general: Se espera que sea comprendido por una audiencia amplia sin conocimientos especializados en el tema o por personas con algún interés en el tema, pero que no necesariamente tengan conocimientos especializados.
4. Propósito general, educativo o informativo: Puede ser informativo, persuasivo o descriptivo, pero no se centra o no profundiza demasiado en detalles técnicos.

Texto especializado:

1. Lenguaje técnico o científico: Utiliza términos específicos del campo de estudio o la disciplina.
2. Dirigido a expertos: Se espera que la audiencia tenga un conocimiento previo en el área específica del texto.
3. Detalles técnicos: Se centra en aspectos técnicos, teorías o metodologías propias del campo especializado.
4. Propósito específico: Puede ser utilizado para comunicar investigaciones, hallazgos científicos, manuales técnicos u otros contenidos que requieran un conocimiento específico del tema.

De manera general para todos nuestros clientes (existen excepciones, que deberían estar reflejadas en el Memo del cliente), cuando el recuento de palabras de un trabajo es muy pequeño, aplicamos unos mínimos de traducción por idioma. La razón por la que aplicamos estos mínimos es porque, aunque el recuento de palabras sea muy pequeño, detrás de la traducción hay un trabajo de gestión algo extenso que realizamos en todos los pedidos. Al cliente se le puede copiar/pegar la explicación de este enlace simplemente para que puedan entender el motivo de aplicar estos mínimos, donde hemos intentado desglosar más o menos el tiempo mínimo que dedicamos a cualquier tipo de trabajo.

En cuanto a nuestra forma de trabajar, siempre contabilizamos en nuestros presupuestos las palabras totales que tienen estos los archivos y aplicamos un descuento por las repeticiones y traducciones previas (100% fuzzy match) que hayamos realizado para el cliente. Estas coincidencias con trabajos anteriores y repeticiones las cotizamos a la mitad de la tarifa de traducción, puesto que en función de dónde aparezcan estas repeticiones (es decir, dependiendo del contexto) es probable que la traducción deba modificarse. Aun así, esto supone un descuento en el precio final de los trabajos.

Por otro lado, para que se contabilicen las repeticiones entre los archivos, las frases tienen que ser exactamente iguales. Es decir, si entre una frase y otra existe el más mínimo cambio, por muy iguales que parezcan las frases, no lo son; por lo que no se considerarían repeticiones.

Si el documento es editable y podemos aislar un listado de números, se puede omitir sin problema.

En caso de que el documento sea un PDF, actuaremos según lo que nos diga el cliente.

• Si no dice nada al respecto, lo trataremos como cualquier otra palabra, sea un listado de números o números dentro de frases, es decir, se contará como traducción.
• Si el cliente dice algo al respecto, en caso de que sean listado de números:
  • si no se deben incluir en la traducción: no se contabilizará absolutamente nada.
  • si se deben incluir en la traducción, pero no traducir (ni siquiera hacer nada con los símbolos decimales de puntos o comas), se contabilizará como edición (OCR)
• Si el cliente dice algo al respecto, pero son textos dentro de frases:
  • Se les debe explicar que los números no son “traducibles” pero se cobran porque también trabajamos en ellos, tanto en la edición como en la traducción (no solo el punto decimal, coma, etc., sino también en incluirlo en el lugar correcto dentro del nuevo orden de la frase traducida.

De acuerdo con el PM001, se considerarán urgentes los siguientes trabajos:

• Plazo de entrega inferior a 24h, independientemente del recuento (debe añadirse un día más en el caso de documentos no editables).
• Plazo de entrega superior a 24h:
  • Traducción solamente: cualquier trabajo superior a 2000 palabras/día*
  • Traducción TC: cualquier trabajo superior a 1500 palabras/día*
  • Traducción Revisión: cualquier trabajo superior a 1500 palabras/día*

* En este sentido, debemos tener cierta flexibilidad a la hora de valorar si puede ser estándar o urgente (-10% de margen en el recuento), en función, por ejemplo, de la hora a la que nos solicitan el trabajo, del posible aprovechamiento de memorias, idiomas implicados…

No obstante, y en base a algunas dudas que han surgido para cuestiones concretas, se intenta responder a continuación a algunas casuísticas:

• Traducción de pocas palabras (¿250-500?) para las 14:00 del día siguiente. El cliente envía el encargo a una hora similar. Debemos hacer presupuesto y el cliente lo aprueba, pero desde su aprobación ya no son 24 horas, sino alguna menos, aunque sigue siendo más que factible hacerlo. ¿Cómo lo podemos enfocar?
  • En una situación similar, lo apropiado sería decirle al cliente que le das un límite X para su aprobación a fin de no tener que contabilizar tarifa de urgencia. De ese modo te garantizas que el cliente te lo apruebe rápido y no se demore hasta última hora o incluso la mañana siguiente. Si pasado ese plazo que le has dado lo sigue queriendo, o bien habría que ampliar el plazo o contabilizar urgencia (o excepcionalmente y según el caso concreto, hacer la vista gorda esa vez).

• El cliente envía un email a las 14:00 con su petición, pero no pone en el asunto que se trate de algo urgente (o sí) pero no se puede atender en el momento. Por diferentes circunstancias de producción se acaba atendiendo a las 16:00, y se necesita para el día siguiente a las 14:00 (o incluso a las 18:00), pero el cliente todavía tiene que aprobar el presupuesto. Damos por hecho que técnicamente es factible realizarlo. ¿Cómo lo enfocamos?
  • En líneas generales, el plazo empieza a contar desde el momento en que el cliente aprueba el presupuesto (o envía un email que no necesita presupuesto previo y por lo tanto ya es una aprobación por sí misma). En cualquier caso, si damos por hecho de que se trata de un cliente habitual, o un buen cliente, podemos tener cierta flexibilidad con él y poder contar el inicio desde que envió el mail (siendo que la entrega a la hora que necesita seguirá siendo factible). En cualquier caso, es importante que cuando se le envíe el presupuesto se le dé un límite X para su aprobación a fin de no tener que contabilizar tarifa de urgencia. De ese modo te garantizas que el cliente te lo apruebe rápido y no se demore hasta última hora o incluso la mañana siguiente. Si pasado ese plazo que le has dado lo sigue queriendo, o bien habría que ampliar el plazo o contabilizar urgencia (o excepcionalmente y según el caso concreto, hacer la vista gorda esa vez).

• El cliente nos envía una solicitud muy pequeñita (10-15-20-50 palabras) para traducir a 11 idiomas, de un día para otro. ¿Lo contabilizo urgente?
  • Según el PM001, podemos traducir 2000 palabras/día/idioma. También damos un peso de 0,25 días por idioma, lo que significa que a partir del 5º idioma deberíamos ampliar el plazo 1 día, y a partir del 9º idioma 2 días. Es decir, teóricamente deberíamos contabilizar un plazo de unos 3 días como estándar.Ahora bien, ¿se trata de un cliente habitual? ¿esta solicitud es algo que realizan de forma estándar o es un caso esporádico? ¿Lo están pidiendo por la mañana y se puede entregar al día siguiente por la tarde? ¿Es factible sin demasiado esfuerzo llegar al plazo que piden? Quizás son preguntas que debamos plantearnos a la hora de aceptar pulpo o no. De entrada, deberíamos luchar por ampliar un pelín el plazo, pero en función de las respuestas a estas preguntas se pueda hacer esa excepción.

No. O no necesariamente. Habrá que considerar diferentes factores para tomar esa decisión.

En primer lugar, nosotros sabemos cuáles son nuestras condiciones para considerar un trabajo urgente, pero cada traductor tiene sus propias condiciones, por lo que estas no tienen por qué coincidir con las nuestras. De hecho, puede ocurrir que lo que nosotros consideramos urgente para el cliente no lo sea para un traductor, pero quizás sí para otro traductor. O al revés, que un traductor considere urgente algo que nosotros no consideramos urgente para el cliente.

En segundo lugar, hay traductores que no tienen una tarifa de urgencia como tal. Simplemente tienen capacidad para poder hacer el trabajo o no la tienen.

Por este motivo, la respuesta es que no aplicaremos tarifa urgente al traductor a menos que nos diga que lo hagamos y, en ese caso, deberemos valorar si es razonable aplicársela o no, dependiendo de las condiciones del trabajo, del contexto, de nuestra necesidad... Evidentemente si un traductor tiene un listado de tarifa urgente y conocemos sus características exactas por las que la pide, se puede aplicar de entrada, pero no es lo habitual.

Finalmente, como decíamos, muchos traductores no tienen establecida una tarifa de urgencia porque directamente no la aplican, sino que basan su decisión en función de su capacidad/disponibilidad. En estos casos, y en situaciones donde nos veamos apuradas o veamos necesario contar con la ayuda de dicho traductor, podemos ser proactivos y ofrecerle un coste superior al suyo habitual. No es garantía de que lo vayan a aceptar, pero en ocasiones puede ayudar a desbloquear la situación.

En primer lugar debemos considerar si dicho festivo es de carácter «local», «nacional» o «internacional»:

• Local: no nos afectará realmente porque habrá otras compañeras trabajando y por lo tanto se consideraría en plazo «estándar».
• Nacional (España): esos días es donde ponemos a personal específico (por ejemplo, 12 de octubre). Esos días se consideran festivos para todos los clientes de ámbito «nacional» (España) y por lo tanto sujeto a tarifa de urgencia. Únicamente no se considerará «urgente» para los clientes internacionales.
• Internacional: Por ej.: 1 de enero, 1 de mayo, 1 de noviembre, 25 de diciembre… Esos días no tendremos a nadie trabajando en la oficina, por lo que será imposible entregar ese día. Solamente podríamos entregar ese día si el cliente así lo requiere sí o sí y, en ese caso, deberíamos plantear internamente una guardia y por lo tanto aplicar tarifa de urgencia.

En cualquier caso, y antes de aplicar la tarifa de urgencia, convendría valorar si entregando el día laborable inmediatamente anterior seguiría justificando una tarifa de urgencia o si, aun adelantándolo, entraría dentro de lo que consideramos una tarifa en plazo estándar. En caso de que entregarlo antes fuese susceptible de tarifa de urgencia deberíamos consultar al cliente si se puede organizar para algún día más tarde a fin de no aplicar tarifa de urgencia y, de ese modo, dejar que el cliente pueda decidir.

[Esta respuesta solamente afecta a PMM]

Si solemos hacerlos en determinado plazo es solo porque es el plazo razonable en base al recuento de palabras y número de documentos que recibimos habitualmente. El plazo siempre lo estableceremos con los mismos criterios que cualquier traducción externalizada. Leer Ejemplo – Traducción interna de clientes médicos.

[EN PROCESO DE REDACCIÓN]

Es habitual que los clientes no indiquen un plazo y dicho plazo debe surgir de nuestro lado.

Hemos convenido que el cálculo de días los realizamos dividiendo entre 2000 para el cliente/2500 para el traductor (yo era la única que hacía 1500 para dejar esa holgura en cosas estándar ). En plazos estándar, añadimos algún día más, para tener más margen, conforme veamos necesario según el encargo.

Para plazos en base a un recuento ponderado, se explicará por escrito cómo calcularlo, para tener todas una idea homogénea del volumen de trabajo que requiere un encargo. Se explicará esto por escrito (en Formación? en PM001 – Procedimiento general Gestión de Proyectos? en FAQs?) y se hablará de los distintos «sitios» donde poder ver los reports más allá de cargarlo en Plunet. Luis se planteó la posibilidad de crear una calculadora.

A priori no, ya que como regla general no deberíamos modificar nada que no aparezca como TC, puesto que eso significa que está fuera del alcance del trabajo.

Además, en el caso de traducciones de ámbito médico (Protocolos, ICFs, IBs, etc.), este tipo de trabajos están sujetos a regulación médica específica, donde los documentos pasan por comités de ética en los que solamente se permite realizar cambios en lugares específicos de los documentos. Cualquier otro cambio fuera de ellos podría ocasionar un rechazo por parte de los comités de ética.

En caso de traducciones de ámbito legal (Contratos, por ejemplo), este tipo de documentos suelen negociarse entre diferentes partes, por lo que una actualización de una parte implica que solo esa parte deba modificarse y no el resto, que ya podría considerarse aprobada.

No obstante, y puesto que las casuísticas pueden ser muy variadas: typos o errores muy claros fuera de TC u otros trabajos de diversa índole, en caso de detectar algo que se crea que debe modificarse a pesar de no aparecer como track-changes (TC), debería consultarse con el cliente para saber cómo proceder. Quizás sea necesario indicarlo con comentarios, no hacer nada, o actualizar el presupuesto, según el caso. En cualquier caso, evitaremos cambios puramente preferenciales que nos recomienden los traductores.

De entrada, no debemos hacer cambios en partes del texto que no hayan sido modificadas en el original. Ante casos como este, puesto que tenemos que saber cómo actuar en las partes que actualizaremos nosotros, conviene consultar al cliente. Ante todo, debemos seguir un enfoque consistente en todas las partes que actualicemos nosotros. Se les puede preguntar también si quieren homogeneizar esa cuestión en todo el documento (habría que actualizar el presupuesto o la order) o solo trabajar en las partes con TC.

Es habitual encontrarse con encargos de clientes en los que tendremos que valorar qué podemos hacer con lo que envían para obtener lo que necesitan. En este ejemplo, con lo que envían, no podemos hacer lo que piden. Hay dos opciones principales: pedirles la traducción de la versión anterior que aparece en el original (tachada, digamos), o pedirles el original que coincide en versión con la traducción que han enviado. Si obtenemos ese original, se puede combinar ese con el original actual (aceptando primero los cambios del último). Esos cambios que salgan son todos los que la traducción requiere. Si no pueden conseguir nada de esto, la última opción que nos queda es enfocarlo como revisión, no traducción. Ofrecerles revisar el documento original entero con la traducción que envían (side-by-side) y hacer los cambios que sean necesarios para que coincidan.

El presupuesto, lógicamente, dependerá del alcance real del trabajo.

Si un cliente médico envía un documento con track changes sin una traducción que actualizar, lo más frecuente es que se le haya olvidado enviarla o desconozca que debe hacerlo. Antes de nada, pidámosle la traducción. Si no existe ninguna traducción previa para actualizar, primero habrá que entender qué necesitan: si necesitan que en la traducción que entreguemos aparezcan los TC marcados o no. Si no lo necesitan, simplemente tendremos que aceptar todos los TC del documento y traducirlo entero. Si necesitan la traducción con esas partes TC marcadas, haremos al contrario: hay que hacer una copia del original, rechazar los TC (revertir el documento a la versión anterior), traducirlo entero y, entonces, actualizar nuestra traducción con los TC del original. Se añaden ambos pasos juntos en el Quote/Order/Job: el recuento por palabras (para la traducción "from scratch") además del tiempo correspondiente a los TC.

No hay problema, pero hay que tener algo en cuenta antes de comenzar. Primero, consultar al cliente si necesita que los TC existentes en la traducción queden visibles cuando la actualicemos, o si podemos aceptarlos antes de proceder con este encargo (habitualmente quieren lo segundo, pero se les olvida aceptar los TC antes de escribirnos). Si confirman que necesitan dejarlos visibles y añadir los nuevos TC “encima”, tendremos que mirar primero qué nombre de usuario tienen los TC de la traducción. Habrá que pedirle al traductor de esta nueva solicitud que use un nombre diferente, o si no los TC existentes que se vean modificados por los nuevos se sobreescribirán y desaparecerán, en lugar de quedar los cambios marcados.

IMPORTANTE: Revisar este artículo para dejar Word bien configurado antes de empezar.

Ver Cambiar o unificar el autor en archivos de cambios (TC) y comentarios en Word.

Sabemos que usar un original como back-translation (BT) no es correcto. Debemos explicarle al cliente que una back-translation es un proceso cuya finalidad es comprobar que la forward translation (FT) es correcta y fiel a su original. Hay dos opciones principales: o bien nos envían la BT anterior (los TC del original los traducimos en la FT y, una vez actualizada, los TC de la FT los traducimos en la BT previa) o, si no existe ninguna BT anterior, ofrecemos hacer la BT de la FT entera, no solo de los cambios (aceptando los TC una vez la tengamos actualizada). Una tercera opción, si necesitan sí o sí la BT con los cambios marcados sería hacer la BT de la forward translation tal y como la envían, actualizarla la con los TC del original y, por último, actualizar la BT que habremos hecho con los TC de la FT actualizada.

Si el cliente, a pesar de eso insiste en que incluyamos los cambios de BT en su original, haremos lo que pide, puesto que ya les hemos informado y advertido anteriormente.

Prueba el siguiente truco: En Word, en la pestaña "Revisar" abre la opción "Seguimiento". Ahí verás la opción de Activar y Desactivar "Control de cambios". A su derecha, verás la opción "Mostrar revisiones". Será ahí donde debas desactivar la opción "Formato".

En algunos documentos como, por ejemplo, los Patient Items, aparece algún texto con formato automático.

Suelen ser fechas, versiones, nombres de centros o investigadores…

Este texto se reconoce porque suele estar sombreado en gris, quizás no a simple vista, pero sí una vez que colocas el puntero encima.

En Trados no suele aparecer y por lo tanto, si no nos damos cuenta se queda sin traducir.

Normalmente, dicho texto suele estar vinculado a otro texto del mismo documento y por lo tanto al traducir ese otro texto, encima de dicho campo, al hacer click con el botón derecho “Actualizar campo”, aparecerá ya también el texto traducido.

Si no apareciera traducido de forma correcta, podríamos forzar el texto, escribiendo encima la traducción de forma correcta. Si no sabemos cuál es la traducción correcta, obviamente, se la tendremos que preguntar al traductor.

Si queremos ver las diferencias entre un documento y otro, utilizaremos la opción que nos da Word de comparación de documentos.

Compararemos o combinaremos un documento original (anterior) y uno actual (nuevo).

Tenemos varias opciones:

• Ninguno de los documentos tiene cambios marcados: pestaña Revisar -> Comparar -> Comparar (o Combinar, da lo mismo). Seleccionas el documento original (anterior) y el actual (nuevo) y Word creará un documento con los cambios marcados.
• Uno de los documentos ya tiene cambios:
  • ¿Quieres que no aparezcan los cambios que ya tienen esos documentos y que, por lo tanto, solo aparezcan las diferencias entre el documento original (anterior) y el actual (nuevo)?: Pestaña Revisar -> Comparar -> Comparar: Word te dirá que se van a aceptar los cambios que ya hay en los documentos, por lo que solo aparecerán en el documento comparado los cambios que haya entre el documento original (anterior) y el actual (nuevo=¡).
  • ¿Quieres que aparezcan tanto los cambios que ya tienen esos documentos como las diferencias que haya ahora entre el documento original (anterior) y el actual (nuevo)?: Pestaña Revisar -> Comparar -> Combinar.

Si en un PDF para traducir hay texto ya en idioma target o bilingüe, o si el cliente pide no traducir determinadas partes, por el motivo que sea, deberemos valorar si esas partes deben figurar en nuestra traducción o si simplemente debemos obviarlas y no hacer nada de nada con ellas.

Si no hay que hacer nada de nada con ellas, simplemente se omitirán (no se hará OCR ni nada), y por lo tanto no se presupuestarán.

Si el cliente quiere que aparezcan, deberemos hacer OCR con ellas y por lo tanto el proceso estándar para calcular el recuento será el siguiente: contabilizar el total de palabras, sumar 10% y restar todas las partes que no requieran traducción.

Para clientes a los que cobramos aparte la edición, se analizarán los documentos sin esas partes que no hay que traducir, pero en File Preparation debemos incluir el total de palabras de los OCR iniciales.

Cuando el documento sea verdaderamente largo y el recuento para traducir verdaderamente bajo, la PM tiene que valorar cómo de mínimo es lo que requiere traducción y qué coste implicaría la edición. De manera general, no cobramos edición a nuestros clientes sino de una manera indirecta, sumando 10% al recuento total. Si el coste de edición no será muy alto, el coste de traducción lo cubrirá sin problema. Seguiríamos el enfoque estándar (ver pregunta "Un cliente pide traducir un PDF donde hay un par de párrafos que no habrá que traducir, porque ya están en idioma target. ¿Cómo contabilizamos esto de cara al cliente?").

Si el incremento del 10% está lejos de cubrir el coste de edición o si lo que hay que traducir es solo un apartado muy localizado y el cliente notaría fácilmente que hemos contabilizado palabras de más, se puede tratar como una excepción donde la edición se contabilice aparte. Estimamos el coste de la edición y se añade como horas de File Preparation, explicando al cliente que esta vez el coste de la traducción no logra cubrir el de la edición del documento entero. Para clientes a los que cobramos aparte la edición, no cambia el proceso habitual con ellos (ver pregunta "Un cliente pide traducir un PDF donde hay un par de párrafos que no habrá que traducir, porque ya están en idioma target. ¿Cómo contabilizamos esto de cara al cliente?").

En caso de que el documento que tengas que traducir contenga imágenes no editables lo primero de todo sería informar al cliente de ello y consultar qué debemos hacer con esas imágenes.

Una primera aproximación podría ser enviar al cliente el presupuesto y decirle claramente qué es lo que hemos presupuestado: ¿traducción de imágenes con entrega en texto plano? ¿traducción de imágenes y maquetación de la traducción? ¿no lo hemos incluido? Y decirle que en caso de que haya que actuar de otro modo, que nos diga. De ese modo somos proactivos y con el presupuesto el cliente puede ver qué incluye y qué no. Es importante ser muy clara y explícita dentro del cuerpo del email en decirle lo que incluye y lo que no incluye.

En caso de que haya que traducirlas o maquetarlas, procederemos del siguiente modo:

• Traducción: se contabilizará el recuento de palabras que tengan, incrementándose en un 10% como cualquier documento no editable. Es muy habitual que no se pueda hacer el recuento fácilmente. Se puede hacer un recuento «a ojo». Por ejemplo, contando las palabras de una imagen «promedio» y multiplicarlo por el total de imágenes, o contar las palabras de una línea «promedio» y multiplicarlo por el total de líneas, o algo similar.
• Maquetación: el tiempo medio de maquetación de cada imagen (bien en forma de edición «source» para hacerla traducible, o bien para recrearla en target) será de 20 minutos, por lo que habría que multiplicar el número total de imágenes por 0,33, lo que resultará en un tiempo de DTP. El tiempo resultante está sujeto a redondeo al alza, de 15 en 15 minutos. Asimismo, este proceso está sujeto a un mínimo (normalmente afectará en caso de que haya 1 o 2 imágenes solamente). Existe una calculadora (Cálculo de tiempo para imágenes (a cliente)) para facilitar estos cálculos. En este punto podemos tener cierta flexibilidad. Imaginemos un buen cliente médico donde tenemos que traducir un protocolo o algo de un gran volumen y que tiene 1 o 2 imágenes. Siempre se puede hacer la vista gorda a dicha imagen si se considera oportuno, aunque tampoco habría problema en cotizarla puesto que, a fin de cuentas, es un tiempo extra que debe dedicarse al trabajo. Esto último podría depender del conocimiento histórico del cliente. En esos casos debería consultarse el procedimiento habitual con dicho cliente específico.

NOTA 1: el promedio de tiempo por imagen está calculado en base a imágenes sencillas, no demasiado grandes y que contengan cuadros de texto (o similar) con fondo plano. En caso de imágenes más grandes, con mucho texto o con complejidad (ejemplo, un fondo que es una imagen, o degradado, etc.), debe consultarse de forma específica antes con el maquetador para tener una previsión de tiempo y poder presupuestar adecuadamente.

NOTA 2: es importante tener en cuenta todos los pasos que deban realizarse a fin de contabilizar el plazo adecuadamente, e incluso valorar la posibilidad de realizar un trabajo en paralelo: traducción de imágenes primero y maquetación (a la vez que se realiza la traducción del resto).

NOTA 3: es importante verificar en los trabajos de TC si hay imágenes que hayan cambiado, pues también deberán tenerse en cuenta (o no, según instrucciones del cliente) para el presupuesto.

NOTA 4: ver caso práctico.

Esta nota solo hace referencia a la configuración del proyecto en Trados.

• Idioma origen: El idioma de origen que elegiremos siempre será la variante dialectal (locale/flavour) principal de dicho idioma, independientemente de lo que indique el cliente en su correo respecto a la variante de origen. Por ejemplo, en el caso de español sería la variante de España, en el caso de francés sería la variante de Francia, en el caso de italiano la variante de Italia, en el caso de portugués la versión de Portugal, etc. Para inglés, utilizaremos siempre la versión US.
• Idioma destino: En la medida de lo posible, intentaremos configurarlo para la variante real a la que se traducirá. Por ejemplo, francés de Francia o francés de Canadá, portugués de Portugal o Portugués de Brasil/Mozambique…, español de España o español US/MX/AR/Latam…, etc. En el caso de inglés (solamente), siempre elegiremos como destino la versión US (a menos que exista una memoria específica en otra variante para dicho cliente).

Nunca debe indicarse la variante de un idioma cuando este idioma sea «source» (ni en Plunet, TMs, SDLXLIFFs, presupuestos, CoTs, footers, etc. El idioma «source» será siempre el que se considere genérico.

Solamente y de forma absolutamente excepcional se podrá utilizar en caso de que el cliente lo requiera por cualquier motivo que vaya más allá de nuestras posibles explicaciones llegado el caso. Si esto ocurre debe consultarse con la Responsable cuál es la mejor forma de hacerlo.

Las variantes de idioma solamente se utilizarán en caso de idiomas «target».

Excepciones: Con el cliente PSI se añade variante source en los siguientes casos: back-translations (solo en footers y CoTs) y adaptaciones (solo en Quotes/Orders).

La variante en idioma de destino (target) la indicamos siempre.

[Excepción que solamente afecta a PMM]

• NOTA relativa al inglés: salvo algún cliente puntual que nos pide traducción a inglés de determinada variante (se indicará en su memo en Plunet), nuestros principales clientes nunca han expresado su preferencia por una variante u otra. Habitualmente traducimos más hacia inglés de Estados Unidos, pero borramos siempre la variante target en Quotes/Orders, para evitar hacerlo explícito y que puedan empezar a solicitar otra cosa. Solo se incluye para esos clientes que sí piden una variante particular.

Se toma el idioma source para todos los tipos de trabajos de revisión y todos los tipos de clientes y equipos.

En aquellos casos donde el cliente solicite que se introduzcan los TC (track-changes) del «source» en su correspondiente «target» y que además se revise completamente la traducción, el proceso será el siguiente:

1. Contabilizar los TC como si fueran solamente para traducir.
2. Contabilizar TODO el «source» como si fuera para revisar.
3. La suma de 1 y 2 darán el resultado del tiempo que deba emplearse.

En Plunet, tenemos 2 opciones:

1. Crear un Job asignado a la persona interna que realizará esa parte del proceso.
2. En caso de no crear un Job asignado a la persona interna que realizará esa parte del proceso debería indicarse en en el Memo de la Order, de la siguiente forma: "Traducido usando plantilla previa y revisado por [nombre de la gestora]". En caso de que se realice revisión, lógicamente debería sustituirse "Traducido" por "Revisado".

En cualquier caso, es importante que quede reflejado puesto que por cuestiones de auditorías de Calidad ISO es necesario que figure esta información en las Order

Si el job quedó Requested, al traductor le sale en su Dashboard y desde ahí podrá aceptarlo o rechazarlo, sin embargo, debemos avisarle de algún modo. Enviamos un email (fuera de Plunet), con el código del Job en el asunto y le damos los detalles que habríamos querido darle en el email de Plunet, pidiéndole que acepte/rechace el encargo a través del Dashboard.

Hay algunos clientes que, de manera interna, usan un código distinto al código de protocolo oficial, que es el que nosotros usamos para facturación y con el que registramos los proyectos. Debemos aprender a distinguir cuándo están diciéndonos un código interno y no el oficial, y encontrar y usar el oficial*. Podemos contrastarlo en varios sitios: el asunto del email del cliente, el contenido del email, el nombre del archivo para traducir, dentro del archivo para traducir, por ejemplo, en el footer/header o en la primera página a veces se indica. Si dentro del documento aparece el título del estudio, podemos buscar algunas palabras en el buscador del listado de títulos del CRM y ubicar el código de protocolo. Incluso encontrando el nombre del promotor podremos realizar búsquedas en Gmail/CRM para ver qué estudios suyos tenemos registrados. Ante la duda, consultemos al cliente.

*A excepción de uno-dos estudios muy puntuales que piden facturar conforme a su código interno. Estos los conocemos con la práctica.

Distinguir cuál es la versión correcta y pedirle a los administradores de Plunet que modifiquen la otra. Para ello, las siguientes indicaciones: si son el mismo código pero uno con el nombre del promotor delante y otro no, damos prioridad al que no tiene el nombre del promotor delante. Si hay más diferencias, valoremos cuál es el código de protocolo oficial (hay que usar ese). Ver pregunta "No encuentro el estudio que indica el cliente en Plunet, ¿es nuevo, o de qué forma puedo confirmarlo?".

La respuesta corta es preguntar al cliente, pero sabemos que a veces hay que tomar una decisión para poder hacer la entrega y entonces preguntarles. Valoremos si las diferencias son de contenido/significado. A menudo cambia alguna palabra o la estructura pero no el significado. Si es ese el caso, se puede usar el título del CRM y añadir un comentario para informarles de que el título del original no coincide al 100% pero hemos usado la traducción aprobada. Si el significado cambia y no tenemos margen para preguntar al cliente cómo quiere que procedamos, mejor traducirlo siguiendo el original pero comentarles lo que ocurre y que sepan que no hemos usado la traducción aprobada.

Cada cliente quiere facturar este tipo de encargos de una manera diferente. PSI lo llama “Corporate” y MDP “General/Internal Costs” (o “General/Legal” si el documento es legal). Aparecen dentro de los listados donde indicamos el estudio en Plunet.

Podremos encontrarlo en el asunto del email del cliente, el contenido del email, el nombre del archivo para traducir, dentro del archivo para traducir, por ejemplo, en el footer/header o en la primera página a veces se indica. Si dentro del documento aparece el título del estudio, podemos buscar algunas palabras en el buscador del listado de títulos del CRM y ubicar el código del estudio. Incluso encontrando el nombre del promotor podremos realizar búsquedas en Gmail/CRM para ver qué estudios suyos tenemos registrados. Puntualmente también realizamos traducciones que no se asocian a ningún estudio. Nos piden imputarlas a Internal Costs/Legal (anotaremos eso donde solemos anotar el Study). Si ningún dato nos da pistas del estudio, podría ser eso, así que consultemos al cliente.

Dejemos todo tal y como está, porque es así como ha recibido el cliente el presupuesto, para que quede igual en la factura.

De todos modos es importante informar a SM del posible error a fin de que puedan corregirlo en futuras ocasiones.

Esta respuesta pretende servir de orientación de los pasos a seguir dependiendo del tipo de situación o de la fase en que se descubre ese error que hace necesario corregir Quote/Order. El enfoque a seguir depende también de si hay que cambiar Quote y Order o solo una de ellas, si existe presupuesto previo a la Order o no y, sobre todo, del tipo de error que haya que solucionar. La PM tendrá que identificar a qué categoría corresponde su caso en particular. Veamos a continuación posibles supuestos.

CAMBIOS QUE AFECTEN AL COSTE O AL ALCANCE / SERVICIO DEL PROYECTO (p. ej., la ISO aplicable)

Hablamos de un cambio en el número de documentos para presupuestar, cambio en el recuento, cambio de modalidad estándar/urgente, añadir/eliminar/cambiar idiomas, añadir/eliminar distintas tareas en el presupuesto, etc.

En estos casos, lo primero que debemos tener claro es que todo cambio ha de hacerse también en el presupuesto (si existe). Si tenemos una Order que proviene de un Quote, aunque ya tengamos el trabajo en marcha, los cambios debemos hacerlos también en Quote, y enviárselo al cliente para que tenga el presupuesto corregido. Ante este tipo de cambios relevantes, Quote y Order deben coincidir y debemos enviarle el presupuesto actualizado al cliente. Haremos los cambios en el presupuesto siempre creando una nueva versión, mediante Correction. No modificaremos directamente el presupuesto que ya habíamos enviado al cliente.

NOTA: Para minimizar la posibilidad de cometer algún error de costes relacionado con las pricelists, lo primero que debemos hacer siempre al crear un Presupuesto/Order es comprobar que aparece la pricelist correcta (la que aplique. La general o la específica del cliente, si la tiene) cuando creamos la(s) combinación(es) de idiomas. El modo de confirmarlo es entrando en el perfil del cliente y viendo su(s) pricelist(s). Por ejemplo, en un encargo a varios idiomas, si en una determinada combinación no sale la misma pricelist que en el resto de combinaciones, eso quiere decir que esa combinación exacta (ya sea por el idioma o incluso por la variante) no existe dentro de la pricelist del cliente. Quizás es lo esperable, y se deba a que es la primera vez que el cliente nos solicita ese idioma, en cuyo caso habría que registrar primero el precio para esa combinación dentro de la(s) pricelist(s) en el perfil del cliente. Sin embargo, también podría ser una primera señal de algún error, por ejemplo, de haber registrado una variante incorrecta para ese cliente. Si no estás segura de si se ha usado esa combinación anteriormente con ese cliente o si las pricelists que aparecen son las correctas, puedes mirar primero qué pricelists y combinaciones de idiomas tiene el cliente en su perfil (o buscar Orders anteriores en “Status report – Orders”).

Para hacer las correcciones, procederemos de distinta forma dependiendo de la situación exacta:

• El presupuesto ya se ha enviado al cliente, pero todavía no lo ha aprobado.

Puesto que el cliente todavía no lo ha aprobado y, por lo tanto, aún no se ha pasado a Order, corregiremos el presupuesto (versión Correction) y se lo enviaremos al cliente con la explicación pertinente. Tras su confirmación, pasamos la nueva versión del Quote (la Correction) a Order.

En este caso, puesto que nos hemos dado cuenta del error antes de comenzar, no es necesario crear una incidencia interna-cliente.

• El presupuesto ya ha sido aprobado (pero todavía no hay Order creada).

Lo primero que habría que hacer es valorar si asumimos el error (no modificamos nada) o si se lo indicamos al cliente (modificando el presupuesto). Sea lo que se decida, en este caso sí habría que crear una incidencia interna-cliente, bien porque afecta al cliente/coste para el cliente o bien porque ha afectado a nuestro trabajo.

Si decidimos indicárselo al cliente, puesto que aún no se ha pasado a Order, habría que corregir el presupuesto (versión Correction), enviárselo al cliente con la explicación pertinente y pedirle que confirme de nuevo si lo ponemos en marcha. Tras su confirmación, pasamos la nueva versión del Quote (la Correction) a Order.

• El presupuesto ya ha sido aprobado (y ya hay Order creada).

Lo primero que habría que hacer es valorar si asumimos el error (no modificamos nada) o si se lo indicamos al cliente (modificando el presupuesto y Order). Sea lo que se decida, en este caso sí habría que crear una incidencia interna-cliente, bien porque afecta al cliente/coste para el cliente o bien porque ha afectado a nuestro trabajo.

Si decidimos indicárselo al cliente, tenemos 2 opciones, según nos resulte más conveniente:

• • Eliminar la Order que hay creada (más conveniente si no hay Jobs creados aún). Corregir el presupuesto (versión Correction), enviárselo al cliente con la explicación pertinente y pedirle que confirme de nuevo si lo ponemos en marcha. Tras su confirmación, pasamos la nueva versión del Quote (la Correction) a Order.

Cómo hacerlo en Plunet: el presupuesto ya se había pasado a Order inicialmente (aunque la hayamos borrado), así que para poder emitir una nueva versión necesitaremos primero cambiar el status del presupuesto a “In preparation” en los apartados que se muestran en la siguiente captura.

Una vez creada la Correction, la versión anterior quedará con status “Revised” automáticamente, y la Correction quedará “Pending”. Es correcto. Enviaremos el presupuesto corregido al cliente y le pediremos que nos confirme de nuevo si lo ponemos en marcha. Tras su confirmación, pasaremos la Correction a Order y ya quedará con el status que corresponde (“Changed into order”).

• • Utilizar la Order que hay creada. Corregir el presupuesto (versión Correction), enviárselo al cliente con la explicación pertinente y pedirle que confirme de nuevo si lo ponemos en marcha.

Cómo hacerlo en Plunet: para poder emitir una nueva versión del presupuesto habrá que cambiar el status como se describe en la captura de pantalla anterior. Una vez creada la Correction, la versión anterior quedará con status “Revised” automáticamente, y la Correction quedará “Pending”.

Cuando el cliente dé el OK a la nueva versión de presupuesto, se puede retomar la Order que teníamos creada. En ella, corregiremos manualmente en los items el error que había que corregir (ver cómo en el ejemplo práctico que se incluye al final de esta pregunta) y podremos poner en marcha el trabajo. Hay que tener en cuenta que siempre que pasamos un Quote a Order se crea un vínculo entre ellos. En este caso, esta Order que ya teníamos creada mantiene su vínculo con el presupuesto inicial, que ya no es el aplicable. Tendremos que actualizar el código de presupuesto dentro de la Order, en los items. Ver FAQ "Cómo incluir o actualizar un número de presupuesto en una Order".

Dentro del presupuesto aplicable (la Correction) cambiaremos manualmente el status a “Changed into order”.

CAMBIOS MENORES

Hablamos de alguna cuestión técnica que no afecta a los costes, por lo tanto, no implicará crear una incidencia interna-cliente. Ante la duda, consulta a tu superior.

En proyectos para los que exista un presupuesto, estos cambios menores no requieren crear una nueva versión del presupuesto mediante Correction. No es relevante mantener la versión enviada y, además, una Correction. Podemos modificar directamente el presupuesto enviado.

Este tipo de cambios en ocasiones se originan por alguna petición del cliente, por ejemplo, de cambiar algún nombre de archivo, y esto puede llegar en cualquier punto del proyecto:

• El presupuesto ya se ha enviado al cliente, pero todavía no lo ha aprobado.

La clave cuando se trata de cambios menores es preguntarle al cliente si les es suficiente con tener ese dato en cuestión corregido en la factura o si prefieren tenerlo corregido también en el presupuesto. Si es lo primero, bastará con corregir la información en la Order, así que no haría falta modificar el presupuesto. Podemos esperar a que confirmen el proyecto y, al pasar el Quote a Order, modificaremos lo que sea necesario en la Order. Sin embargo, el esfuerzo de dejarlo corregido ya en el presupuesto es mínimo, y así evitaremos que se nos olvide hacer la corrección que sea en la Order. Por ello, recomendamos hacer los cambios en el presupuesto enviado y que, de esa forma, pase a Order con la información correcta. Ya que modificaremos el presupuesto, no nos cuesta nada enviárselo actualizado al cliente (o le preguntamos si lo quieren).

• El presupuesto acaba de ser aprobado (pero todavía no hay Order creada).

Como decíamos en el caso anterior, podemos preguntarle al cliente si con tener ese dato en cuestión corregido en la factura es suficiente o si prefieren tenerlo corregido también en el presupuesto, y actuar de un modo u otro en función de sus necesidades. Si no les importa el presupuesto, no hay impedimento en pasar el presupuesto enviado (sin corregir) a Order y hacer los cambios necesarios dentro de la Order.

• El presupuesto ya ha sido aprobado (y ya hay Order creada).

Si ya se ha pasado a Order y estamos trabajando en la solicitud, podemos hacer los cambios en la Order y preguntarles si les basta con que aparezca corregido en la factura (solo cambiaríamos la Order) o si necesitan que les enviemos también el presupuesto actualizado (cambiaríamos Order y Quote, por separado, como se ha explicado con anterioridad en este artículo).

-------------------

Ejemplo práctico específicamente enfocado a cambios en las combinaciones de idiomas

Cómo modificar el Quote:

• (1) Para que Plunet te permita modificar el presupuesto habrá que cambiar el status como se explica en la captura de pantalla anterior.

Si no se trata de un cambio de idioma sino de cualquier cambio técnico dentro de los items existentes (cambios en nombres de archivos, otro recuento de palabras, etc.), omitir pasos 2-4. Modificar el contenido de los items tal y como necesitemos y saltar al paso 5.

• (2) Eliminar la combinación incorrecta desde el apartado Languages.
• (3) Crear ahí la combinación correcta. Hay que asegurarse de que la casilla “Only create newly added languages” está marcada y hacer clic en “Create items”. Tendremos aún la combinación anterior dentro de los items, por si interesa comparar la diferencia de coste.
• (4) Eliminar el item con la combinación de idiomas incorrecta.
• (5) Guardar los cambios, opcional: si hay una Order ya creada, cambiar de nuevo el status del presupuesto a “Changed into order”, enviar el presupuesto corregido al cliente y (si procede) pedirle que confirme de nuevo si lo ponemos en marcha.

Cómo modificar la Order:

El problema a la hora de modificar items dentro de la Order podría venir si ya hay Jobs creados y si los cambios que hay que realizar afectan a esos Jobs (por ejemplo, cambios en combinaciones de idiomas). Si es el caso, los cambios hay que hacerlos primero en Job list y después en Order details, en ese orden. Si intentamos borrar items de la Order y detecta que hay Jobs creados, no dejará eliminarlos.

• (1) Eliminar todos los Jobs creados dentro de la combinación de idiomas que hay que borrar. Si están “In preparation”, dejará eliminarlos.
• (2) En la Order, hacer lo mismo que se ha hecho en el presupuesto (apartado anterior). Para que la modificación quede correctamente registrada, hacer clic de nuevo en “Order confirmation”.
• (3) Volver a crear los Jobs que sean necesarios, ya en la combinación de idiomas correcta en Job list.

NOTA: La combinación de idiomas exacta (la misma variante) debe coincidir siempre entre la Order y los Jobs. Dicho de otro modo, si en Order tenemos una variante errónea para ese cliente y nos diéramos cuenta más tarde y quisiéramos asignarlo al traductor habitual de ese cliente (que traduce a otra variante), el sistema no lo permitirá. Habría que crear un ajuste de relay language.

En todo caso, como hemos visto, lo más frecuente será solucionar el error en la variante; no será frecuente que decidamos dejar una variante en Order y otra en Job list.

Recuerda que, tras solucionar un problema con una combinación mal escogida (es decir, tras haber eliminado el idioma incorrecto y creado el correcto), para asignar el trabajo correctamente debemos analizar los documentos de nuevo en Trados con la combinación correcta, para subir a Plunet el SDLXLIFF y el report correctos. Por ejemplo, si inicialmente presupuestamos/registramos todo como PT-PT pero hemos corregido todos los registros a PT-BR, el SDLXLIFF y el análisis guardados no son aplicables para el traductor final que se ocupará de la traducción. Hay que analizar los documentos de nuevo y utilizar los archivos correctos; a efectos técnicos, un cambio de variante lo convierte en un idioma distinto.

• El cliente quiere cancelar un pedido que ya está en marcha
• El cliente quiere parar hasta nueva orden un pedido que ya está en marcha

Depende del caso exacto. Si es una referencia general y el cliente no obliga a usar las mismas palabras, el documento para traducir se analiza de manera normal para el cliente. Simplemente enviaremos la referencia al traductor para que le sirva de ayuda.

Si tenemos que usar las mismas palabras que aparecen en el documento de referencia, pero este es largo y hay que ir buscando aquí y allá las partes que podemos reutilizar, también se analiza entero y de manera normal el documento para traducir y se le envía la referencia al traductor indicándole que debe usar el texto tanto como pueda. Si tenemos que usar las mismas palabras pero son unas pocas frases, muy fáciles de ubicar (ejemplo, Queries Letter), se le puede enviar al traductor y pedirle que use esa traducción (al cliente no se le descuenta nada) o podemos copiar la traducción de esas frases ya dentro del SDLXLIFF y bloquear esos segmentos. No se tarda demasiado, ya nos aseguramos de que se usa la traducción correcta y son elementos tan localizados que mejor no cobrarle al cliente esas partes. Se analiza la copia con los segmentos bloqueados.

En caso de SoC (Summary of Changes), ver "Cómo gestionar un Summary of Changes (SoC)".

Depende. Eso nos puede indicar que es muy probable que ya hayamos traducido antes ese documento o uno muy similar. Conviene determinar si lo tradujimos ya (deberíamos detectar esto a tiempo y advertir al cliente) o si tradujimos una versión anterior y esta es una nueva. Si fuera eso último, lo que tendría que valorar cada PM (dependiendo del caso, la potencial complejidad de este nuevo encargo, etc.) es si comentarle al cliente lo que ha descubierto y ofrecer enfocarlo como un trabajo de track changes (TC) comparando el documento original del encargo anterior con el del nuevo y actualizando la traducción anterior con esos cambios, o no decir nada y proceder con la traducción integral del documento tal y como lo enfocaba el cliente. En estos casos siempre es recomendable consultar opinión con alguna compañera con mayor experiencia.

Podemos comprobar si es el mismo documento comparando el documento source anterior con el actual. Si confirmamos que parece ser el que ya tradujimos, conviene compartir con el cliente lo que hemos encontrado, dándole algún detalle de cuándo nos solicitaron ese encargo, le enviamos la traducción (y el certificado) que les enviamos en su día y le pedimos que confirme si no tenemos que iniciar esta nueva solicitud.

Importante: antes de enviar las traducciones previas es importante verificar si no existe alguna cláusula de confidencialidad con el cliente que lo impida, como por ejemplo NVCR.

Tenemos las siguientes posibilidades, ordenadas de forma preferencial:

1. Añadir un registro del traductor en el Excel de accesos de traductores y asignarle un código. Aunque el traductor no disponga de accesos a los recursos siempre se le puede registrar y asignar el código. Simplemente es importante asegurarse de que el código es único. Cuando se decida darle credenciales al traductor se acabará de completar ese registro del Excel.
2. Anotar el nombre completo (solo nombre) del traductor/revisor que, normalmente, ya nos servirá de orientación si vemos esa info en la TM.

Es mejor que no, puesto que si la entrada en el CRM incluye varios certificados, aunque solo necesitemos modificar uno, tendremos que enviar al cliente todos los CoT de esa entrada modificada, ya que el código de verificación anterior queda obsoleto en todos los certificados.

En este sentido, lo mejor es simplemente borrar el certificado (solo ese certificado) que no sirve y crear una entrada nueva en el CRM para ese CoT nuevo.

• Hemos generado tan solo 1 pdf: Si la herramienta lo permite, debe modificarse desde dentro del CRM. Si la herramienta no lo permite, se puede editar el pdf manualmente y reemplazarlo. En cualquiera de los dos casos, no importa si ya hemos enviado el pdf al cliente y nos ha pedido cambios o hemos visto la necesidad antes de enviárselo.
• Hemos generado varios pdfs y tenemos que modificar uno (o varios) de ellos: Aquí diferenciaremos si ya lo hemos enviado al cliente o todavía no.

Si todavía no hemos enviado los pdfs al cliente y la herramienta lo permite, debe modificarse desde dentro del CRM. Si la herramienta no lo permite, se puede editar el pdf manualmente y reemplazarlo.

En caso de que ya hayamos enviado los pdfs al cliente, tenemos 2 opciones: (1) eliminar solo ese certificado en el que hay que hacer cambios (usando la X) y generar uno nuevo, o (2) editarlo manualmente y reemplazarlo (usando el lápiz).

NOTA: En caso de fallo, solicita el reemplazo a Ana/Luis.

¿Cómo se hace? Una vez generado el pdf mediante la plataforma y descargado y editado manualmente, hay que ir a «Editar»:

1. en caso de querer eliminar uno de ellos (en el caso de que haya varios), la opción a utilizar es la X en lugar del lápiz.
2. en caso de que se reemplace algún documento, ya no funcionará la opción de editar el contenido con el CRM (en realidad sí funcionará, pero ese reemplazo que se acaba de hacer quedaría machacado).
3. el filename (el que aparece fuera, nombrando el archivo pdf) no cambiará, siempre se mantendrá igual que el que ya había (aunque se renombre en el PC de otro modo).
4. si lo que ha fallado es precisamente ese «filename», no es necesario reemplazarlo. Se puede enviar con la modificación al cliente, ya que la verificación se hace con el contenido, no con el «filename» que nombra al pdf.

A priori no. Si se modifica el PDF de forma manual, el código de verificación llevará al cliente al CoT que hay dentro del CRM, por lo que la información que verán no coincidirá con el PDF corregido. Si las correcciones que hay que hacer se pueden hacer desde dentro del CRM, habrá que corregirlo dentro de la entrada existente en el CRM y enviar el nuevo CoT que se genera. Cada cambio que hagamos, al guardar, genera un nuevo código de verificación.

Aún así, es probable que en un momento dado no se pueda modificar desde dentro del CRM porque por el tipo de cambio sea necesario editar el contenido del PDF (OJO, hablamos del contenido, y no del filename que aparece "fuera", nombrando el archivo .pdf) y que eso no funcionase con la herramienta. En este caso, donde la única solución pasaría por editar el pdf directamente, se puede reemplazar el pdf directamente en el CRM.

¿Cómo se hace? Una vez generado el pdf mediante la plataforma y descargado y editado manualmente, hay que ir a "Editar":

 

Ahí aparecerían los archivos con el icono del lápiz y el de la x. Haciendo click en el del lápiz se podría reemplazar por el nuevo documento. De ese modo, si el cliente quiere verificarlo, verá el nuevo documento.

 

Notas importantes:

1. en caso de que se reemplace algún documento, ya no funcionaría la opción de editar el contenido con el CRM (en realidad sí funcionaría, pero ese reemplazo que se acabaría de hacer quedaría machacado).
2. el filename (el que aparece fuera, nombrando el archivo pdf) no cambiará, siempre se mantendrá igual que el que ya había (aunque vosotras lo nombréis de otro modo).
3. si lo que ha fallado es precisamente ese "filename", no es necesario reemplazarlo. Se puede enviar con vuestra modificación al cliente, ya que la verificación se hace con el contenido, no con el "filename" que nombra al pdf.

El cliente MDPF suele aceptar un CoT por encargo, donde se listan varios documentos a la vez.

MDPS y PSI prefieren un CoT por cada documento.

Los Study Titles o Títulos de estudio se añaden en el momento en que lo traducimos a cualquier idioma (se crea el estudio nuevo y se añade el o los idiomas que tengamos). No esperamos confirmación por parte del cliente; por defecto, lo dejamos registrado. Si más adelante el cliente realizase cualquier cambio, lo modificaremos en el CRM. Para más información sobre cómo registrarlos, ver Formación específica de PMM.

En encargos “mixtos”, podemos hacer como para los clientes que piden un CoT por documento, o bien hacer un CoT por tipo de documento, es decir, un CoT con la leyenda de TC para todos esos documentos y otro CoT normal para el resto.

La que aparezca dentro del footer de la traducción. Si no la envían cuando piden el CoT, nos tendrán que indicar ellos qué fecha quieren que pongamos (o, si no lo hacen, les preguntamos).

Como siempre, es importante tratar de avanzarse a cualquier tipo de imprevisto. En este sentido, si antes de sacar el trabajo a traducir ya sabemos que vamos a tener que introducir unos footers en el documento, es conveniente introducirlos antes de sacar el trabajo a traducir. De ese modo evitaremos dejarlos para el final y que puedan llegar a acarrear sorpresas por falta de tiempo el día de la entrega, problemas cuando algún encargo queda pendiente en ausencia de la PM que lo ha estado gestionando, peleas con el formato en el momento de sacar el footer existente y meter el de PSI, etc. Además, a excepción de traducciones a inglés donde ya nos sirve el filename del documento, la línea de descripción del tipo de documento ha de traducirse, de modo que en general resulta más conveniente dejarlos ya metidos antes de sacar el trabajo a traducir.

A partir de ahí, se puede elegir si dejarlo visible, ocultarlo (para desocultarlo antes de la entrega) o dejar visible las partes del footer que requieran traducción.

[Esta respuesta solamente afecta a PMM]

En el día a día hacemos algunas preparaciones de archivos para clientes que no les cobramos (por ejemplo, los Patient Items a doble columna) porque no conllevan un tiempo relevante. Cuando la preparación de archivos suponga de media hora en adelante, es justificable cobrarlo/presupuestarlo, como ocurre en el caso del Excel bilingüe o la traducción de contratos que quieren recibir a doble columna, donde hay listados/enumeraciones que arreglar.

Para facilitar el proceso, se ha desarrollado una Macro y filtro, cuyo funcionamiento puede leerse aquí.

En cualquier caso, a efectos de presupuesto, se estiman 20 segundos por celda, y se puede calcular fácilmente con la Calculadora.

Si existen nuevas directrices que se solapan de algún modo con entradas ya existentes en la base terminológica, las existentes ya no aplican (se debería confirmar primero con el cliente la información para verdaderamente registrar lo que tengamos que seguir en el futuro). Se deberán borrar y añadir las nuevas entradas.

Si la entrada existente es muy similar en estructura, se podría reutilizar y modificarla como sea necesario, aunque quizás lo más fácil para el especiaista sea borrar las entradas existentes y crear las nuevas.

Lo más relevante para el correcto funcionamiento de la base terminológica es crear dos entradas: una con la forma desarrollada y otra con la sigla. Más información en Añadir términos a una base terminológica (TB).

La respuesta rápida es que para poder preparar un presupuesto necesitamos que el cliente nos facilite los textos para traducir en el formato editable que le sea más cómodo.

Los formatos más habituales suelen ser:

• Word o Excel
• Archivos exportados mediante los CMS o gestores de contenidos (xml, xliff, csv, html, php…). La forma de exportarlo depende de cada gestor de contenidos.
• Mediante WPML, en caso de que la web esté realizada con WordPress y tenga el plugin WPML. Ver formación en Okodemy de «Presupuestos web con WPML».

En todos los casos, nosotros devolveremos la traducción en esos mismos formatos.

No podemos aceptar que nos envíen la URL de la web y nos digan «ahí tienes», puesto que no podemos estar copiando/pegando los textos de todas las páginas para un recuento. Normalmente es irreal además de costoso en cuanto a tiempo. Esto solo podría realizarse en caso de una única página (o varias, pero algo más que no nos vaya a conllevar más de 10-15 minutos de copiar/pegar).

Ver punto 2.4 del manual PM001 - Procedimiento general Gestión de Proyectos.

No, porque ese estado implica que el traductor ya ha enviado su factura para ese trabajo y, en principio, ya ha sido procesada correctamente por el departamento de Facturación.

En todo caso, escribiremos a Facturación para exponer el caso y consultar cómo proceder.

La respuesta corta y fácil es sencillamente todos los que puedas.

Sin embargo, debemos ser realistas y conscientes de que se trata de un festivo donde el número de gestoras trabajando es mínimo, y por lo tanto la capacidad de gestionar está limitada.

En este sentido, lo que se espera es que las gestoras sean capaces de identificar aquellos trabajos que deben gestionar ese día sí o sí y darles prioridad, dejando de lado aquellos trabajos que pueden esperar porque dicha espera no compromete el cumplimiento del trabajo.

Ahora bien, una vez gestionados los trabajos prioritarios y si hay tiempo, se espera que se saquen esos otros trabajos menos prioritarios.

A fin de establecer un paralelismo, se recomienda leer el artículo ¿Cómo organizar el horario? y actuar de modo similar al que se indica en las franjas de 17 a 18h y 18 a 19h, aunque teniendo en mente que esas dos franjas (17 a 19h) serían aplicables a todo el día en el caso de los festivos.

• ¿Es urgente o se prevé ayuda de OCR por parte de proveedor? ♦ Sacar a traducir / Consultar disponibilidad. En este caso, confirmar o no confirmar al cliente podría depender de la hora y de la urgencia real percibida.
• ¿No es urgente? ♦ Solamente sacar a traducir si diese tiempo. Si no, para el día siguiente.

En cuanto a responder a los clientes, puesto que se trata de un festivo, solamente responderemos a aquellos clientes para los que no sea festivo también. Por ejemplo, para un 12 de octubre donde solamente es festivo en España, responderemos a los clientes de fuera de España*, pero no a los españoles dado que sobreentendemos que tanto para ellos como para nosotros es festivo.

* Estas respuestas se harán para todos los emails como si de un día normal se tratara. En caso de que, como se indicaba anteriormente, no se pueda gestionar su trabajo/email, al menos confirmaremos recepción y diremos que lo miramos y le daremos una respuesta posteriormente.

Sabremos que un texto ha sido añadido por el traductor y eliminado por el revisor cuando está tanto subrayado como tachado:

Para que el cliente no lo vea y le genere confusión, lo que haremos será aceptar la eliminación del revisor. Así, el texto añadido y posteriormente eliminado se eliminará de forma definitiva y no se verá ningún cambio.

Si en el QA vemos que en la termbase no hay preferencias específicas para el idioma/variante del proyecto, no es relevante utilizar la TB en ese caso. Si la hubiera, sí recordemos cargar en Xbench la TM específica del cliente.

En estas situaciones no hay una política de empresa como tal, sino que se plantea la posibilidad de que las compañeras hablen entre sí y decidan cómo proceder, ya que se pueden dar situaciones muy diferentes o trabajos de envergadura diferentes. Desde el punto de vista de la empresa, lo más lógico sería que lo continúe aquella persona a la que le sea más fácil/cómodo seguirlo por haberse empapado del proyecto, bien por la preparación del presupuesto o bien por la gestión de la Order.

En cualquier caso, sí es de especial relevancia indicar en el Memo de cualquier proyecto que sea un pelín especial aquello que se haya hecho o que haya que tener en cuenta, a fin de que otras compañeras sepan qué ocurre con ese trabajo especial en caso de una ausencia. Un ejemplo de ello podría ser si se oculta texto en Word, ya que no es algo que se haga habitualmente, o si hay que hacer algo en particular o, en definitiva, si hay que tener algo en cuenta más allá de lo que sería un trabajo estándar.

• Presupuestos:

Si hay que preparar presupuesto para el cliente, en Plunet podemos indicar la última fecha de entrega, pero no está de más que en el presupuesto (lo descargamos en .rtf para poder modificarlo) agreguemos en la columna de la fecha de entrega las diferentes fechas de las entregas parciales. Si esto no se hace, como mínimo, ha de quedar acordado por escrito en el email al cliente.

• Orders:

Programaremos la Order para la primera fecha de entrega para evitar olvidos involuntarios y, cuando se realice esa entrega parcial, la PM modificará la fecha (de la propia Order y de los items) a la siguiente fecha de entrega. Así hasta la entrega final. Es más, si el elemento de la entrega parcial se ha presupuestado en un item independiente, se puede programar cada item con su correspondiente fecha de entrega y, al devolver la entrega parcial, cambiar el estado del item a Delivered. Si todos los documentos están juntos en el mismo item, no se cambiará a Delivered con la entrega parcial.

• Jobs:

El job se enviará también con la primera fecha de entrega, para que Plunet nos sirva como recordatorio de que estamos esperando una entrega parcial. Se le explicará al traductor que, cuando entregue, modificaremos la fecha de entrega a la siguiente fecha de entrega y modificaremos el estado del job de Delivered a In progress.
Al revisar las entregas parciales para entregar, guardaremos los archivos en VER y también en Final dentro de la Order, para que sirva de prueba de que ya se envió al cliente.

Si un traductor nos alerta de un error en la TM, deberemos ponernos en contacto con JMM. En el correo, le detallaremos:

• En qué TM está el error (nombre de la TM y combinación de idiomas)
• Cuál es el segmento original
• Cuál es el segmento erróneo
• Cuál es el segmento correcto

Por ejemplo:

Te escribo porque necesitamos que modifiques la memoria “medical” en la combinación en>es.

SEGMENTO ORIGINAL
Your personal data will be used for only as long as needed for the study and further research related to HAE, with your consent.

SEGMENTO ERRÓNEO EN LA TM
Sus datos personales se utilizarán solo mientras sean necesarios para el estudio y para investigaciones adicionales relacionadas con el AEH, sin su consentimiento.

SEGMENTO COMO LO NECESITAMOS
Sus datos personales se utilizarán solo mientras sean necesarios para el estudio y para investigaciones adicionales relacionadas con el AEH, con su consentimiento.

Esto aplica principalmente a los archivos de COFEPRIS de PSI, en especial a las secciones debajo del título “Cadena original”, como se observa en la siguiente captura:

Son secciones extensas que incluyen muchos códigos, números y texto traducible. En primer lugar, el cliente ya confirmó que ese contenido se traduce (no así los códigos/links debajo de los títulos “Firma” y “Certificado”). A veces, el texto ya suele estar traducido, así que es importante controlar esto para excluirlo del presupuesto, si corresponde. Ya se realizaron varias traducciones de estos documentos, así que el cliente espera que haya mucha coincidencia de TM y pide explicaciones.

Puede ocurrir que envíen varios documentos similares que incluyan estas secciones y que el análisis de Trados resulte con una cantidad de palabras nuevas considerable (y es probable que el cliente pregunte el motivo). Si esto pasa, antes de enviar el presupuesto, un paso extra de verificación es comparar los archivos para ver si estas secciones son idénticas. Si efectivamente es así, una solución es copiar y pegar el mismo texto en todos los archivos en cuestión. De esta manera, el análisis de Trados va a ser más adecuado: el contenido solo saldrá como palabra nueva una vez y el resto como repeticiones.

Si al comparar, vemos que las secciones no son idénticas, el conteo inicial de Trados es válido y se justifica (si preguntan) con que ese contenido exacto no se tradujo anteriormente y por eso sale, en mayor parte, como palabras nuevas. Por supuesto, esto no aplica para PDF escaneados que no se pueden comparar.

Es importante facilitar toda la información de la que dispongas. ¿En qué Request/Quote/Order/Job/Invoice/... estabas? ¿Qué estabas haciendo justo antes? ¿Cuáles han sido los pasos que has seguido hasta llegar al error? Lo que estabas creando, ¿cómo lo has creado?

Además, es importante si puedes enviar el logger de Plunet, que se encuentra, en Plunet, arriba a la derecha donde el muñequito, Help, Download log files.

Como norma general, todo aquello que tengamos estandarizado se debería presupuestar de acuerdo con los procedimientos generales, y en caso de que no lo tengamos procedimentado debería avisarse (mediante la creación de una Incidencia) para tratar de procedimentarlo.

En aquellos casos donde se trate de algún tipo de trabajo no estándar o que no se pueda procedimentar, deberemos aplicar un margen al coste que nos facilite el proveedor.

También, en caso de necesidad de salir del paso en un momento puntual donde todavía no haya algo procedimentado se puede aplicar este criterio de añadir un margen al coste que nos facilite el proveedor.

Ejemplos de trabajos estandarizados:

• Preparación de archivos (source/target)
• Edición de imágenes
• Transcripciones
• Subtítulos
• Maquetaciones de documentos editables

Ejemplos de trabajos no estandarizados:

• Maquetaciones de documentos no editables
• Edición de vídeo
• Trabajos creativos desde cero
• Compra de elementos necesarios para algún trabajo en concreto (música, programa, etc.)

Que aparezca un altísimo número de 100% matches (o incluso 95-99%, ya que habitualmente este rango muestra diferencias solo de formato, o de alguna palabra suelta) es un primer indicativo que nos podría hacer pensar que ya hemos traducido ese documento con anterioridad. En ese momento, procederemos del siguiente modo:

La primera comprobación sería abrir el archivo como para traducir y consultar varios segmentos aleatorios a lo largo de todo el archivo para confirmar si los 100% matches de la memoria provienen todos del mismo documento. Para ello, en la ventana de resultados de la TM, nos fijaremos en la fecha y la abreviatura del traductor. Si coinciden en fechas/autor, podemos sobreentender que se trata del mismo documento y por lo tanto buscaremos el proyecto en nuestra base de datos para confirmar que efectivamente se trata del mismo documento (ver PF42. Al analizar un documento para un nuevo encargo he descubierto que ya tradujimos ese documento hace unos meses. ¿Qué debería hacer?). Tras la comparación y en caso de que se confirme que es el mismo documento, se le puede enviar la traducción al cliente (en casos de clientes médicos, acompañado del certificado de traducción que se envió en su día). Excepción: NVCR no permite enviar traducciones previas a cualquier persona de la empresa sin un consentimiento expreso.

En cuanto a costes, a priori no se le cobraría ese archivo al client ni se trabajaría en él. (Excepción: si se ha trabajado en la edición de un documento no editable).

Cuestiones previas a considerar:

• Los 100% matches no son todos del mismo documento: en este caso no podemos considerar que este documento lo hayamos traducido como tal, sino que se trata de un documento nuevo. No es raro traducir documentos que puedan contener partes ya traducidas en otros proyectos anteriores.
• Ver todo como 100% match no suele engañar, pero ver a simple vista (o mediante comparación) que el documento es muy muy parecido a otros que hemos traducido con anterioridad no debe confundirse con "es el mismo documento". Imaginemos que ese tipo de documento es alguno de los que traducimos con frecuencia y, por defecto, siempre son muy similares (por ejemplo, ocurre con frecuencia con los tipos de documentos médicos para los que se hace traducción interna). Hay documentos que, en cuanto cambie una fecha o un párrafo, se considera un documento nuevo, porque lo normal es que sean así de similares.
• Sale todo al 100% match en la memoria pero ¿es una TM general? ¿El documento que se tradujo previamente fue para este mismo cliente? Si no fue para este mismo cliente, debemos considerarlo un trabajo nuevo que, como mínimo, se deberá revisar (no podemos entregar a un cliente una traducción tal cual la hemos realizado para otro cliente diferente). De cara al presupuesto/pedido, seguiremos nuestro procedimiento habitual aplicando el recuento del análisis con la TM, aunque para el trabajo con los proveedores, podemos enfocarlo como revisión.
• Para clientes médicos, podría ocurrir que se haya traducido el documento para un estudio y ahora lo pidan para otro. No hay problema y por supuesto no requiere traducir de nuevo. Se les puede explicar que ya se tradujo para otro estudio y enviar el documento (a excepción de NVCR), e incluso hacer un nuevo certificado para el segundo estudio, si lo requieren. Entendemos esto como algo puntual, pequeño y esporádico. Si fuera frecuente, o envían una ristra de documentos para los que hay que generar CoTs, debemos plantear de contabilizar, al menos, un tiempo de gestión que justifique el trabajo administrativo que nos plantea ese trabajo.
• IMPORTANTE: Debe recordarse que si descubrimos que un documento ya lo tradujimos con anterioridad, no se incluirá en el proyecto. Si todo el proyecto consistía en la traducción de ese único documento, se cancelará el proyecto y no se le facturará nada al cliente, a excepción de cualquier fase que hayamos tenido que realizar hasta el momento, por ejemplo edición de PDF (con posibles excepciones cuando el importe sea muy bajo). Ver PF42. Al analizar un documento para un nuevo encargo he descubierto que ya tradujimos ese documento hace unos meses. ¿Qué debería hacer?).

No tenemos forma automática de ver la configuración de idiomas de los archivos .xliff. El único modo de hacerlo es manualmente (abriendo cada archivo, uno por uno).

Con un número reducido de archivos, es posible valorarlo y hacerlo de este modo. Cuando hay muchos, deberíamos solicitar al cliente que vuelva a exportar, idioma por idioma para facilitar el recuento de palabras por idioma.

Se puede nombrar de un modo que refleje de manera representativa el tipo de documentos que incluye el CoT. Por ejemplo, "SPR201 - patient items" (código de estudio - tipo de documentos). En ocasiones podemos usar el asunto del email del cliente, pero solo si es representativo. Si se complica, no hay problema en preparar un CoT por documento.

En ocasiones nos encontramos con situaciones donde debemos entregar un trabajo de calidad en un plazo de entrega muy ajustado y para ello todo debe salir rodado. Si hay alguna parte del flujo de trabajo que se atasque podría hacer peligrar el plazo de entrega. Las causas pueden ser variadas, como por ejemplo un trabajo de traducción revisión a una variante de idioma con la que hay gran diferencia horaria (EN > ES_PE, por ejemplo), los recursos tardan en responder o lo hacen cuando nosotros ya no estamos en la oficina, no tenemos suficientes recursos fiables para esa combinación/especialidad, etc.

Es importante tener en cuenta 2 aspectos fundamentales y que deben ser la base sobre la que actuar para encontrar una solución:

1. Tratar de realizar el proceso de trabajo habitual siempre que sea posible, ya que lo que se propone en esta respuesta sirve solo como solución excepcional.
2. Tener en cuenta que la entrega al cliente debe basarse siempre en dar una respuesta a sus especificaciones/necesidades/expectativas. Ver Gestión de proyectos en Okodia.

A partir de aquí, algunas soluciones excepcionales podrían ser las siguientes:

• PROBLEMA: No tenemos traductores para esa combinación.
  • SOLUCIÓN: Podemos plantear realizar una traducción puente a fin de poder tener traductores nativos.
• PROBLEMA: No tenemos traductores nativos para esa combinación.
  • SOLUCIÓN: Podemos plantear realizar una traducción con un traductor no nativo y posteriormente una revisión (proofreading) monolingüe del target, a fin de asegurar que no hay errores lingüísticos en lo que entregaremos al cliente (* esto no aplicaría en caso de que al cliente se le haya informado específicamente que no contamos con traductores nativos, tras consultar con Dirección). Si el revisor tiene alguna duda sobre lo que está leyendo, puesto que no conoce el idioma origen, es necesario coordinar sus dudas con el traductor inicial.
• PROBLEMA: No tenemos traductores de confianza y que respondan a tiempo (normalmente por diferencia horaria) y no podemos esperar un día a su respuesta. Esto normalmente ocurre con variantes específicas de algún idioma (por ejemplo español de Perú).
  • SOLUCIÓN: Podemos plantear la traducción con un traductor nativo de una variante con mayor confianza o que respondan a tiempo y realizar la revisión (que realmente debería ser revisión y adaptación) con un traductor nativo de la variante target. Esto ayudará a ganar tiempo en la respuesta de esa variante específica mientras se puede poner en marcha la traducción inicial.

Es importante recalcar que estas soluciones son solo soluciones temporales y excepcionales a problemas del día a día, pero que deben solucionarse para trabajos futuros, cuando ocurra. En caso de que se detecte que esto se tiene que realizar de forma sistemática debe avisarse a Recursos Humanos a fin de poder encontrar una solución real a dichos problemas.

A veces utilizan una misma traducción para más de un estudio clínico y, aunque ya les hayamos enviado un certificado, piden otro para otro estudio. No hay problema, mientras sea tal cual la traducción que nosotros hemos realizado. (Si han hecho modificaciones, habría que revisarla).

Esta pregunta no es tan sencilla de responder, puesto que depende básicamente de los idiomas/países/traductores involucrados.

La respuesta que más podría encajar con lo que espera el cliente es que si es festivo en España (nacional, no local/provincial), es lógico que ese día no se trabaje y por lo tanto no se contabilice. Esto podría verse así puesto que los clientes suelen pensar que los traductores están en la oficina trabajando y por lo tanto, si no abre la oficina, ellos no trabajarán tampoco.

Sin embargo, la situación real es que depende de si el traductor X tiene festivo ese día o no. Es decir, podría darse el caso de una traducción de español a inglés, que pide un cliente francés, en cuyo plazo cae un festivo en España, pero que la traductora está en EE. UU. En esta situación concreta, la traductora no tendrá festivo y trabajará durante ese día normalmente, como cualquier otro día laborable.

También podría darse otra situación, y es que en ese mismo ejemplo el festivo no estuviera en España sino en EE. UU., y muy probablemente nosotros no sabríamos de antemano que era un festivo en EE. UU., por lo que lo normal es que no hayamos tenido en cuenta ese festivo en el plazo ofrecido al cliente. La situación con la traductora sería que o bien no puede cumplir el plazo o bien tendríamos que buscar una alternativa de traductora.

En cualquier caso, lo conveniente sería poder valorar todas las posibilidades y si es absolutamente necesario contar ese día como festivo o no teniendo en cuenta los diferentes aspectos:

• idiomas y traductores involucrados
• dónde se encuentra el cliente

Ejemplos:

• Si el cliente se encuentra en España y los idiomas/traductores involucrados son de España, el cliente lo va a entender perfectamente y nos da ese margen adicional, por lo que se puede considerar festivo.
• Si el cliente se encuentra en España pero los idiomas/traductores involucrados no son de España, aunque el cliente seguramente lo entendería, realmente no afectaría demasiado, así que no sería necesario considerarlo festivo (a menos que ese día pueda dar cierto margen extra a la entrega).
• Si el cliente no se encuentra en España y los idiomas/traductores involucrados tampoco, no deberíamos considerarlo festivo puesto que realmente no va a afectar en absoluto.
• Si el cliente no se encuentra en España pero los idiomas/traductores involucrados sí son de España, deberíamos valorar si es necesario tratar con el cliente ese día adicional (o considerarlo directamente en el plazo), o si por el contrario no es realmente necesario (en función de cada caso: podemos buscar una alternativa con traductores para los que no es festivo, o que trabajarán igualmente en el festivo, o incluso que el traductor vaya más rápido y pueda hacerlo igualmente a pesar del festivo...).

Solamente se confirmará al cliente la puesta en marcha del proyecto cuando dicho proyecto se haya puesto efectivamente en marcha, es decir, no se confirmará al cliente la puesta en marcha antes de haberlo puesto realmente en marcha. No es necesario esperar la confirmación de los proveedores para confirmar el trabajo al cliente, pero sí realizarlo en ese orden: el cliente confirma que quiere realizar el proyecto -> lo ponemos en marcha -> confirmamos al cliente que lo ponemos en marcha.

Si por ejemplo tenemos un trabajo con varias combinaciones en las que tenemos que hacer MTPE solo para alguna de ellas, lo correcto sería incluir una anotación a mano en el presupuesto (RTF) donde se indica la norma ISO correspondiente para cada combinación. No haría falta crear dos presupuestos diferentes para cada ISO.

La ISO que se debe incluir en estos dos casos es la misma: ISO9001:2015, ya que la ISO17100:2015 solamente es aplicable a trabajos de traducción (humana). Por lo tanto, la ISO17100:2015 solamente se debería utilizar en los trabajos donde haya que hacer una revisión de aquello que hemos traducido, es decir, para el servicio de Traducción y Revisión únicamente. En cualquier caso, en trabajos de revisión o de prooreading, tampoco debería haber mayor problema (aunque no sería lo estrictamente correcto) si se indica la ISO17100:2015 puesto que se podría sobreentender que estamos haciendo una parte del proceso completo.

Normalmente son los traductores quienes deberían indicar sus propias tarifas, por lo que en primer lugar deberíamos animarles a que ellos den el primer paso. En cualquier caso, podemos orientarles e indicarles que a la práctica, habitualmente las tarifas de MTPE son alrededor de un 40% más bajas que las de traducción humana. No obstante, también convendría ver las tarifas de nuestros proveedores más usuales y darle datos más específicos como ejemplo, tratando en cualquier caso de incentivarle a ofrecer tarifas más cercanas a las más bajas que solamos manejar (siempre estarán a tiempo de rechazarlo o incrementarlas).

Siempre que sea posible, debemos evitar dejar trabajos "pendientes" a otras compañeras. Algunas pautas para lograrlo:

• Si somos quienes proponemos la fecha de entrega al cliente, evitemos fijarla en un festivo o en un día en el que no estaremos disponibles.

• Si el cliente solicita una entrega en una fecha concreta que coincide con un festivo, intentemos adelantarla o, si es viable y con la autorización del cliente, retrasarla para no dejarlo pendiente a otra persona que trabajará dicho festivo.

• Si ya has terminado un proyecto cuya entrega coincide con un festivo o con tu ausencia programada, déjalo entregado con antelación, evitando que otra compañera tenga que encargarse.

• En los casos en que no quede más remedio que dejar un trabajo pendiente, deja hecho todo el trabajo que puedas anticipar y toda la información bien organizada y documentada, de forma que otra persona pueda retomarlo fácilmente.

Sabemos que no siempre es posible preverlo todo, pero hagamos un esfuerzo consciente por no sobrecargar a las compañeras cuando esté en nuestra mano evitarlo.

En primer lugar debemos verificar si lo que nos dice es correcto o si por el contrario el traductor/revisor está trabajando con otro documento diferente del que debería. Estas comprobaciones deben realizarse con los documentos que el cliente ha enviado originalmente para asegurarnos al 100% de que el problema viene causado de origen. Si el problema no viene causado de origen, verificaremos en qué punto se ha producido el problema (nuestra preparación interna, el paso de traducción, etc.), y trataremos de solucionarlo según corresponda. Si el problema viene causado de origen preguntaremos al cliente cómo proceder.

Habrá que confirmar con el cliente si quiere que creemos un presupuesto por cada estudio o quiere que facturemos todo el trabajo bajo un único estudio. De ser este segundo caso, nos debe confirmar a qué estudio lo tenemos que facturar.

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.

Ver Controles de Contenido, Metadatos y Bibliografía de Word en Trados Studio.

Ver Configuración estándar Trados Studio.