Internacionalización del sitio web

Para facilitar el proceso de localización web y que este dé lugar a un producto de calidad óptima, es conveniente implementar un proceso de internacionalización del sitio web durante su desarrollo. Este proceso puede resumirse en las siguientes fases (adaptado de Esselink, 2000):

1. La arquitectura del sitio web deberá permitir el almacenamiento y visualización de contenidos en varias lenguas. Si se emplea un sistema de gestión de contenidos (CMS por sus siglas en inglés), este debe permitir la creación de sitios web multilingües; por ejemplo, mediante el uso de plugins como WPML (WordPress) o FaLang (Joomla). Otra opción es crear un sitio web independiente para cada locale. Esta última opción suelen emplearla grandes empresas con una presencia física significativa en las regiones meta.
2. Se distinguirá entre aquellos textos del sitio web que se someterán a un proceso de traducción convencional y aquellos que habrán de reescribirse o someterse a un proceso de transcreación para lograr una adaptación completa a las expectativas del público meta. Esta última es la opción más recomendable cuando se trata de textos publicitarios o de marketing.
3. Se determinarán las herramientas informáticas que se emplearán para mantener el sitio. Por ejemplo, se puede combinar el uso de un CMS multilingüe con herramientas que monitoreen cambios y actualizaciones en el contenido y con una memoria de traducción que favorezca la consistencia de los contenidos.
4. Se diseñará un plan de actualización y mantenimiento del sitio.

Una vez seguidos estos pasos, será el momento de elegir a un proveedor de servicios de localización que traduzca el contenido del sitio web. Ciertas empresas con gran presencia en algunos de sus mercados se decantan por la creación de contenido de forma local en lugar de la localización.

Diseño web: otras consideraciones

Además de la necesidad de incorporar una fase de internacionalización del sitio web, Esselink (2000) señala una serie de aspectos a los que habrá de atenderse durante la fase de diseño:

• Colocar un selector de idioma que emplee los nombres de las lenguas en lugar de sus banderas (ver por ejemplo el de nuestro sitio web, situado en la parte superior izquierda). Estas últimas imponen barreras de accesibilidad (ver más información en nuestras Recomendaciones) y no son correctas cuando las lenguas a las que hacen referencia se hablan en varios países, como es el caso del español o el inglés.
• Mostrar el selector de lengua en todas las páginas web, no solo en la página de inicio, y evitar que el uso de este redirija al usuario a dicha página inicial.
• Comprobar que el sitio web es compatible con los sets de caracteres de las futuras lenguas meta. El estándar de codificación Unicode es compatible con la gran mayoría de lenguas del mundo.
• El diseño del sitio web deberá ser lo suficientemente flexible para acomodar direcciones, fechas, hora, moneda, números de teléfono, apellidos, divisiones administrativas (provincias/estados), etc. que sigan convenciones de formato diferentes a las de la locale. 

A la hora de desarrollar las páginas web individuales, son recomendables las siguientes pautas:

En la medida de lo posible, emplear iconos que no provoquen confusiones ocasionadas por las diferencias culturales (iconos de buzones que solo son identificables para el público norteamericano, por ejemplo). Evitar un uso excesivo de imágenes con texto y procurar guardar los archivos originales con el texto traducible en una capa de texto separada. Emplear identificadores para las variables que no sean palabras para evitar que estos se consideren texto traducible y se alteren durante el proceso de localización. Limitar el conjunto de etiquetas HTML que se emplean y utilizarlas de forma homogénea. No introducir etiquetas de formato excesivas en el texto. Emplear diseño adaptable (responsive design). Si es necesario, incluir comentarios en el código para explicar scripts, códigos de applet, etc. No emplear la tecla de tabulación o los espacios para aplicar formato al texto. Permitir que las tablas ajusten su tamaño de forma automática. Para ello, no introducir etiquetas a fuego (hard-code) que determinen de forma fija la altura o anchura de las tablas en el código HTML. Emplear el atributo lang para delimitar párrafos o páginas escritas en lenguas diferentes (por ejemplo, <html lang=»fr»> para documentos enteros o <p lang=»fr»>Ceci est un paragraphe.</p> para un solo párrafo en otra lengua).

Icono que representa un buzón típico de algunas regiones angloparlantes como Estados Unidos. (creado por Smashicons de www.flaticon.com, licencia CC 3.0 BY)

Sitios web estáticos frente a dinámicos y uso de CMS

En el pasado, la mayoría de sitios web en Internet eran estáticos. Una web estática es un conjunto de páginas HTML entrelazadas que contienen referencias a otros elementos dependientes (archivos de imágenes, sonido, vídeo, hojas de estilo, scripts) y que muestra el mismo contenido para todos los usuarios. Este tipo de sitios web son fáciles de desarrollar, solamente requiere el empleo de un lenguaje de programación básico como HTML y están pensados para no ser actualizados con demasiada frecuencia. Por el contrario, los sitios web dinámicos (la mayoría en la actualidad) adaptan el contenido que ofrecen a cada usuario y para ello emplean lenguajes de secuencias de comandos como PHP y ASP para cuya manipulación se requiere mayor experiencia y conocimientos en programación. Las webs dinámicas contienen aplicaciones dentro de la propia web que permiten interactuar con el usuario, tales como encuestas, foros, envío de correos electrónicos inteligentes, reserva y pedidos en línea, atención al cliente personalizada, etc. Constituyen la base de la Web 2.0., y a pesar de su complejidad permiten a un usuario sin conocimientos de desarrollo web crear y mantener un sitio entero mediante el uso de sistemas de gestión de contenidos (CMS) como WordPress o Joomla.

La traducción de una web estática es un proceso sencillo puesto que solo requiere descargarla con algún tipo de software específico (o recibir los archivos por parte del cliente) e importarla a una herramienta de TAO. Por el contrario, la traducción de una web dinámica, con frecuencia generada mediante el uso de CMS como WordPress o Joomla, puede suponer un proceso más complejo. A este respecto puede consultarse Torres del Rey y Rodríguez V. de Aldana (2013, 2014) y la entrada de blog Mitos y verdades sobre la localización de sitios y páginas web hoy en día (Muñoz Sánchez, 2014).

El trabajo del gestor de proyectos o project manager resulta determinante para que el encargo de localización pueda llevarse a buen término. Entre otros aspectos, los gestores de proyecto se encargan de elaborar presupuestos, reunir los recursos necesarios para el encargo, distribuir el tiempo disponible entre las diferentes tareas, asegurar la calidad del producto final y gestionar la comunicación entre los diferentes agentes.

Los gestores de proyectos suelen emplear algún tipo de software de administración de proyectos para distribuir las tareas entre los agentes participantes en el encargo (Microsoft Project, por ejemplo). También les puede resultar valioso el empleo de obras de referencia como la Guía de los fundamentos para la dirección de proyectos (Project Management Institute, 2017). A continuación proponemos una serie de recomendaciones para el desempeño de algunas de las actividades más frecuentes de un gestor de proyectos.

Preparación del proyecto

Durante las fases de evaluación y preparación del proyecto, será preciso recopilar la totalidad de la información necesaria para su ejecución. Para ello, puede resultar de utilidad plantearse las siguientes cuestiones:

• ¿Qué costes, tiempo y recursos exige el proyecto, cuáles son los problemas que pueden surgir durante su ejecución y qué subetapas deberá incluir la fase de garantía de la calidad (quality assurance)?
• ¿Cuáles serán los entregables?
• ¿Se cuenta con todos los archivos necesarios para la localización?
• ¿Será necesario traducir todos los archivos?
• Si el cliente nos indica el número total de palabras, ¿es este correcto?
• ¿Compensa el uso de una memoria de traducción para reciclar traducciones previas? ¿Es posible emplearla?
• ¿El sitio web original funciona correctamente?
• ¿Cuál es el proceso más eficaz para localizar el producto (descargar el sitio web y traducirlo con una herramienta de TAO, copiar los contenidos a un procesador de textos, solicitar acceso al sistema de gestión de contenidos –CMS– y traducir desde allí…)?

Estimación del tiempo

Resulta esencial calcular y administrar de forma inteligente el tiempo que se invertirá en un proyecto de localización dado que, de todos los recursos necesarios, este es casi siempre el más limitado, y aún más si se tiene en cuenta que para los clientes la entrega a tiempo suele ser la principal prioridad. Como señala Giammarresi (2011), la localización es una tarea compleja en la que confluyen un sinfín de variables que han de concretarse en tareas controlables, de ahí que resulte complicado aplicar un enfoque de producción en cadena que pueda aplicarse a cualquier encargo de localización y que permita calcular el tiempo necesario para cada tarea con total exactitud. Será tarea del gestor de proyectos decidir qué prácticas se aplicarán a cada proyecto dependiendo de la naturaleza de este último con el objetivo de favorecer su buena marcha y que se complete dentro del plazo acordado con el cliente.

En traducciones del inglés a lenguas romances o viceversa, suele calcularse que el número de palabras que un traductor puede traducir al día se sitúa en torno a las 2.500 (Bass, 2006: 77; Chriss, 2006: 35; McKay, 2006: 88). No obstante, este número puede fluctuar enormemente (un traductor puede traducir solo unos cuantos cientos de palabras al día o llegar a más de 10.000) dependiendo de numerosos aspectos. Los siguientes factores pueden mejorar significativamente el rendimiento de los traductores (Dunne, 2011b):

• Requisitos establecidos de forma clara
• Existencia de una memoria de traducción fiable y aprovechable para el proyecto en cuestión
• Existencia de una base de datos terminológica fiable
• Existencia de guías de estilo y corpus de texto revisados y aprobados
• Disponibilidad de otros materiales requeridos
• Amplia experiencia por parte del traductor en el dominio en cuestión
• Experiencia trabajando con el mismo cliente
• Número pequeño de archivos: a mayor número de archivos, mayor tiempo requerido en procesarlos.
• Tamaño del proyecto: un único proyecto de 10.000 palabras suele requerir menos esfuerzo que 5 proyectos de 2000 palabras no relacionados entre sí.
• Texto linear: es más fácil traducir prosa que cadenas de texto aisladas. En el segundo caso, al no existir un hilo narrativo conductor, el traductor ha de imaginar el contexto, por lo que el proceso puede llevar hasta 10 veces más tiempo.
• Ausencia o número limitado de elementos culturales
• Ausencia o escasez de errores en los archivos origen
• Disponibilidad de expertos en la materia que puedan responder a consultas que surjan durante el proyecto
• Uso de tecnología (herramientas de traducción asistida –TAO–, por ejemplo)
• Repeticiones en los archivos (siempre y cuando se emplee una herramienta de TAO)
• Uniformidad terminológica y estilística en el contenido origen

El tiempo requerido para otras actividades como la edición y revisión del texto, la ingeniería de localización y el testeo deberá estimarlo el gestor de proyectos basándose principalmente en su experiencia. Como referencia se puede emplear el número de horas que se necesitaron para completar un proyecto de envergadura similar.

Con respecto al número de horas necesario para la localización de imágenes, se considerarán los siguientes factores:

• Tipo de imagen: capturas de pantalla, arte lineal, etc.
• Complejidad del fondo, la fuente y el diseño empleado en cada imagen
• Disponibilidad de archivos originales con la capa de texto separada del resto

Se recomienda presupuestar de forma separada las imágenes que necesitan mucha edición y retoque y aquellas que sean sencillas (Esselink, 2000).

Asimismo, es importante implementar un plan de contingencia por si surgen imprevistos que retrasen la ejecución de alguna de las tareas del proyecto. Muchos gestores de proyectos añaden un 10% a la duración de cada tarea. Otra opción es añadir algunos días al final del proyecto.

Finalmente, después de definir el tiempo necesario para cada fase, será necesario definir la secuencia en la que estas deberán realizarse, teniendo en cuenta aquellas tareas que necesariamente han de realizarse de manera previa o posterior a otras (la extracción del texto ha de realizarse necesariamente antes de la traducción; la revisión previa a la entrega al cliente debe realizarse después de la integración del texto en el sitio web, etc.).

Estimación del coste

En general, para que el presupuesto sea competitivo, se recomienda dar precios unitarios (precio por palabra, por línea, por página, por caracteres) en lugar de emplear tarifas horarias siempre que sea posible. También es recomendable explicitar las actividades que se incluyen en cada precio unitario. Por ejemplo, se indicará que el precio por palabra traducida incluye edición y revisión.

Ciertas actividades como la preparación del proyecto, ingeniería, testeo, maquetación y localización de imágenes suelen presupuestarse por horas, aunque a veces se emplean otros parámetros como el número de páginas o de imágenes.

La traducción y la revisión suelen cobrarse por número de palabras en la lengua origen, aunque en algunos países o para ciertas combinaciones lingüísticas se cuentan las líneas (unos 55 caracteres) o el número de palabras traducidas. Dependiendo de la complejidad del texto origen y la temática, pueden aplicarse ajustes al precio final. Los textos de carácter legal suelen cobrarse más caros, por ejemplo.

La gestión del proyecto suele facturarse como un porcentaje del coste total, que puede girar en torno al 10%.

Un presupuesto profesional debería incluir la siguiente información:

• Desglose del precio de cada tarea
• Lista de entregables
• Fechas de facturación: un 50% del proyecto se puede cobrar por adelantado y el 50% restante tras la entrega, por ejemplo. Otra opción podría ser cobrar el 30% por adelantado, 30% en un punto determinado del proyecto y 40% tras la entrega.
• Planificación temporal de las tareas del proyecto
• Problemas que pueden surgir durante el proyecto y que retrasarían la entrega
• Información de la empresa (Esselink, 2000)

Establecimiento de parámetros de calidad

El gestor de proyectos deberá asegurarse de que se están llevando a cabo las comprobaciones de calidad previstas para cada actividad. Por ejemplo, durante la fase de revisión lingüística, deberá asegurarse de que los traductores introducen los cambios sugeridos por los revisores. También es recomendable que el gestor solicite a los revisores que creen una lista de los errores más comunes para evitarlos en proyectos futuros.

Por otro lado, con mucha frecuencia los proveedores de servicios lingüísticos no solicitan a los clientes de forma explícita que les indiquen sus necesidades y preferencias antes de llevar a cabo la localización, sino que descubren estas una vez el cliente ya ha recibido el proyecto y lo está revisando. La importancia crucial de evitar que esto suceda reside en que los parámetros que empleará el cliente para determinar la calidad del producto final los constituirán sus propias preferencias. Dunne (2011a) considera que el cumplimiento de dichas preferencias debería ser una prioridad frente a otros factores como la adaptación al público meta o la conformidad con las convenciones lingüísticas formales o referentes al aspecto. Este mismo autor señala que la calidad es una cualidad que no puede definirse de manera universal sino que se trata de un parámetro que se modela para cada proyecto en base a los gustos y prioridades del cliente. La solicitud de una revisión preliminar al comienzo del proyecto puede ser una buena forma de identificar dichas prioridades.

Determinación del grado de adaptación necesario

Esselink (2000) sugiere clasificar las páginas del sitio web objeto de la localización de acuerdo a la siguiente clasificación. Se trata de una clasificación similar a la señalada en el epígrafe Internacionalización del sitio web (dentro del apartado Desarrolladores web) que será necesario aplicar si el cliente o desarrollador web no lo ha hecho de forma previa.

1. Páginas que requieren una gran adaptación cultural o regional (por ejemplo, texto publicitario o de marketing)
2. Páginas que requieren una traducción
3. Páginas que no requieren traducción alguna

En el caso de las primeras páginas, puede ser incluso necesaria una reescritura o transcreación de los contenidos. Las páginas con información técnica sobre un producto, por ejemplo, normalmente se someten a una traducción convencional. Finalmente, las campañas de publicidad locales o la información sobre oficinas situadas en la región de la locale no suelen traducirse.

Los sitios web de comercio electrónico suelen requerir un nivel de adaptación superior puesto que deben ajustarse a aspectos como los sistemas de pago locales, la selección de productos disponible en cada región, el sistema de distribución, el reglamento local referente a impuestos, etc.

Material para traductores-localizadores

El gestor de un proyecto de localización web se encargará de que los traductores-localizadores reciban el siguiente material:

• Planificación temporal incluyendo fechas de entrega
• Instrucciones que indiquen de forma detallada los servicios que se les solicita a los traductores: traducción, edición, incorporación de correcciones realizadas por el revisor, revisión ortotipográfica, actualización de glosarios…
• Archivos en la lengua origen, tanto en su formato nativo como en un formato apto para una herramienta de TAO, si procede. En el segundo caso, lo que se suele hacer es crear un paquete para una herramienta de TAO como por ejemplo Trados. Dichos paquetes incluyen los archivos que cada traductor debe traducir, el archivo de proyecto, la memoria de traducción, etc.
• Otras herramientas de software que se necesiten para completar la traducción
• Material de referencia: glosario del proyecto, glosarios de proyectos anteriores, otros sitios web o productos del mismo cliente, guías de estilo del cliente, sitios web relevantes, documentos Q&A en los que se resuelven cuestiones frecuentes y otros problemas…

Gestión de recursos humanos

En relación a la gestión de los recursos humanos que intervendrán en el proyecto, se tendrán en cuenta los siguientes factores:

• Si más de un traductor trabaja en el mismo proyecto, se designará a uno de ellos como el responsable de la gestión terminológica y de otorgar homogeneidad estilística al texto así como de ponerse en contacto con el cliente o el revisor para consultar aspectos lingüísticos. No obstante, en ocasiones estas tareas forman parte de las responsabilidades del revisor o del project manager.
• Se debe limitar al máximo el número de traductores trabajando en un proyecto para favorecer la uniformidad del producto final.
• Se debe asegurar que todos los miembros del equipo monitorizan sus horas trabajadas (Esselink, 2000).

Los miembros del proyecto encargados de gestionar la terminología (a menudo, uno o varios de los traductores involucrados en el proyecto) asumirán las siguientes responsabilidades:

• Realizar tareas de documentación
• Realizar tareas de compilación de textos
• Realizar tareas de extracción de términos y otras unidades léxicas
• Revisar y aprobar términos y otras unidades léxicas
• Crear y actualizar bases de datos terminológicas
• Evaluar y personalizar herramientas de gestión terminológica y glosarios
• Controlar que todo el equipo (traductores-localizadores, editores, revisores) está empleando los términos registrados en el software de gestión terminológica y en los glosarios.

Como primer paso, es recomendable partir de una recopilación de unidades léxicas. Para ello, los encargados de esta tarea llevarán a cabo las siguientes actividades:

• Identificar palabras clave empleadas en el sitio web.
• Consultar si el cliente emplea un glosario monolingüe para la redacción de los contenidos originales e incluir los términos comprendidos en dicho glosario en la recopilación léxica del proyecto.
• Construir y gestionar un corpus de textos con el objetivo de alimentar y enriquecer la base de datos.
• Utilizar, si es necesario, una herramienta de extracción terminológica.
• Incluir en la recopilación léxica otras unidades comúnmente usadas que, al no considerarse necesariamente propias del proyecto suelen ser olvidadas por lo que, en ocasiones, concentran un elevado número de incidencias (ir arriba, hacer click derecho…).
• Finalmente, las unidades léxicas recopiladas se combinan con sus equivalentes en otras lenguas (identificadas, preferiblemente, mediante la gestión textual previa, el uso de textos paralelos, o incluso mediante el cotejo con otros glosarios o con diccionarios especializados) para crear una base de datos terminológica multilingüe.

Del mismo modo, es conveniente que todos los traductores-localizadores identifiquen y añadan a la base de datos palabras clave conforme traducen. En este caso, es recomendable que el traductor designado como responsable de coordinar la gestión terminológica coteje y compruebe estas sugerencias para que un añadido indiscriminado de palabras clave no cause conflictos indeseados entre la base de datos y el texto final. Además, este control necesario repercutirá en la labor de los agentes encargados de la evaluación final del proyecto.

Finalmente, es conveniente familiarizarse con los estándares terminológicos del área con la que estamos trabajando. En la industria de la localización, el principal referente lo constituyen los glosarios de Microsoft. También se deben considerar los estándares de terminología desarrollados por ISO (Principles and methods of terminology –ISO 704–, Presentation and layout of terminology standard –ISO 10241–, Vocabulary of terminology –ISO 1087–, International harmonisation of concepts and terms –ISO 860–).

Para traductores y localizadores web, ofrecemos una serie de recomendaciones específicas para la localización web que pueden consultarse aquí.

Si existe la figura del ingeniero de localización en el proyecto de localización web, este llevará a cabo tareas como la separación del texto del resto del código y posterior reinserción en el producto localizado. También, si procede, puede llevar a cabo la adaptación de la estructura del sitio web, por ejemplo mediante el uso de un editor HTML con gestión de sitios web (Adobe Dreamweaver, MS Expression Web) (Torres-del-Rey y Rodríguez-V.-de-Aldana, 2014).

En la evaluación final de un proyecto de localización, en la que intervendrán diversos agentes (revisores-editores, testers, operadores de quality assurance), pueden distinguirse tres fases: evaluación lingüística, evaluación visual y evaluación funcional. Las tareas de cada subfase se describen a continuación (adaptado de Esselink, 2000).

Evaluación lingüística

La evaluación lingüística se puede dividir en dos fases:

1. Se comprueba que la traducción cumple con los siguientes requisitos: presenta un nivel de calidad lingüístico satisfactorio, es uniforme desde el punto de vista terminológico y estilístico, su significado es claro, favorece la navegabilidad y usabilidad del sitio, es legible desde el punto de vista web, la gramática y la puntuación son correctas y se emplea el dialecto apropiado para la locale en cuestión.
2. Se comprueba que la traducción refleja posibles cambios realizados en el sitio web durante el proceso de localización.

Evaluación visual

Consiste en verificar que la apariencia final del sitio web cumple las expectativas del mercado meta. Todo el texto debe ser visible, el texto contenido dentro de las imágenes debe haberse traducido, el formato debe ser el correcto y los colores, imágenes e iconografía deben estar adaptados a los usuarios del mercado meta. Es recomendable realizar estas comprobaciones empleando diferentes navegadores y, si es posible, diferentes dispositivos.

Evaluación funcional

En esta fase, se comprobará que el sitio web localizado funciona de manera correcta e idéntica al original y que, por tanto, el proceso de localización no ha afectado a la funcionalidad de la web. En esta fase se pueden utilizar herramientas de validación de sitios web que comprueben que todos los enlaces internos y externos funcionan, así como que todas las imágenes están presentes y no hay etiquetas HTML corruptas. También existen herramientas específicas para sitios web localizados que comparan los archivos originales y los meta y comprueban que ambos conjuntos de archivos presentan las mismas etiquetas y que no se han omitido fragmentos en la traducción. En el caso de sitios web con gran uso de scripting o Java será importante comprobar la funcionalidad mediante una fase de testeo.

En general, aplicar una última fase de validación o de quality assurance es de gran importancia; sin embargo, con frecuencia esta se omite debido a limitaciones del presupuesto o por falta de conciencia sobre la influencia que esta última etapa puede tener en la calidad final del producto (Jiménez, 2016). Por otra parte y como ya se indicó anteriormente, es vital contar con la opinión del cliente en fases previas a la entrega puesto que de lo contrario sus preferencias serán más difíciles y costosas de implementar en el producto final.

Normalmente el cliente revisa el producto entregado al final del proceso, señala posibles errores y con frecuencia solicita que se introduzcan cambios basados en sus propias preferencias. En esta fase en la que el cliente actúa como último revisor deberá tenerse en cuenta que cualquier persona que realice tareas de revisión debería tener un conocimiento mínimo tanto de las lenguas origen y meta y de sus culturas como de los procesos, herramientas y metodologías que intervienen en la traducción y la localización. Si esto no es así, lo más probable es se acaben introduciendo errores en lugar de mejorar la traducción (Dunne, 2011a). No obstante, como ya se ha indicado en el epígrafe Establecimiento de parámetros de calidad (dentro del apartado Gestor de proyectos), las preferencias del cliente casi siempre deberán priorizarse por encima de convenciones o prácticas habituales, por lo que además de la recomendación anteriormente indicada de solicitar una revisión poco después de comenzar el proyecto, lo ideal en proyectos grandes sería que el cliente realizara una revisión por tandas con el objetivo de que los cambios que solicite puedan incorporarse al flujo de trabajo de las fases posteriores (Dunne, 2011a). El problema es que muchos clientes no desean involucrarse en el proceso de localización y preferirían recibir directamente una versión final de la localización. En cualquier caso, es necesario prever la posible existencia de última etapa en la que se incluirán los cambios solicitados por el cliente y se crearán los archivos finales para su entrega.