Escribir un artículo en seis idiomas es la parte fácil. La parte difícil empieza seis meses después, cuando el producto cambia, el original se actualiza y cinco traducciones se quedan exactamente donde estaban. Un cliente lee una versión que describe una pantalla de dos actualizaciones atrás - y abre un ticket en lugar de usar la base de conocimiento.
Qué se desincroniza primero
Los artículos enteros no envejecen todos a la vez - lo primero que falla son los detalles. El nombre de un botón cambia en el producto, y cuatro de cinco versiones de idioma todavía muestran el antiguo. Una captura de pantalla muestra la interfaz anterior al rediseño, porque se tomó una vez, durante la primera traducción, y nadie volvió a actualizarla en cada versión por separado. Un paso que desapareció del producto sigue descrito en el idioma que nadie revisó en la última actualización.
Nada de esto parece grave por separado. Juntos significan que la versión de idioma que el equipo de soporte lee con menos frecuencia se va alejando en silencio de lo que el producto realmente hace hoy.
Cómo no perder una traducción cuando cambia el original
El mayor daño no viene de traducciones malas, sino de que nadie sabe que justo esa necesita una corrección. Una regla ayuda mucho: un cambio en la versión original nunca termina en la versión original - termina marcando las traducciones vinculadas como "pendiente de revisión", aunque la corrección en sí espere una semana.
Mantener las versiones de idioma vinculadas entre sí (la misma entrada conectada por un identificador común) aporta más que un panel ordenado - permite preguntar directamente qué versiones de una entrada no se han actualizado desde que cambió el original. Sin ese vínculo, responder a esa pregunta implica revisar cada versión a mano, algo que en la práctica nunca ocurre.
Un cambio cosmético (una errata, una frase) y un cambio de fondo (un paso distinto en un procedimiento, un precio distinto, una función renombrada) no son la misma operación - solo el segundo exige de verdad que alguien que habla ese idioma vuelva a leer la entrada, y no solo cambie una palabra.
Cómo saber que una entrada ya vive su propia vida
Hay varias señales que aparecen antes de que alguien lea una entrada línea por línea y note la diferencia:
La fecha de última actualización de una versión de idioma es claramente más antigua que las demás, aunque el tema haya cambiado desde entonces - señal de que esa versión se quedó fuera del ciclo de revisión.
Los tickets de soporte en un idioma vuelven al mismo tema con más frecuencia que en los demás, aunque la entrada de la base de conocimiento formalmente lo cubra - normalmente significa que la respuesta en ese idioma ya no corresponde al producto actual, así que los clientes igualmente escriben a una persona.
La terminología se desincroniza dentro del mismo idioma entre entradas - la misma función se llama de forma distinta en un artículo antiguo y en uno nuevo, porque los tradujeron personas distintas en momentos distintos sin un glosario compartido.
Qué vigilar en la práctica
Un único idioma de origen a partir del cual se traducen los demás - sin un original claramente marcado, cada versión acaba viviendo su propia vida, porque no hay nada con qué compararla.
Un identificador común que vincule las versiones de una misma entrada, para poder consultar el par en lugar de revisar cada idioma por separado.
Un glosario breve y vivo de los términos clave del producto por idioma - no para que todos traduzcan igual, sino para no tener que adivinar si "ticket" significa lo mismo en cada artículo de ese idioma.
Revisar no toda la base de una vez, sino solo las entradas vinculadas a lo que acaba de cambiar en el producto - es la única revisión que realmente ocurre, porque se mantiene pequeña y concreta.
Lo que el multilingüismo no resuelve solo
Tener una entrada en seis idiomas no significa que el cliente reciba la misma calidad de respuesta en cada uno - si una versión se actualiza cada semana y las demás una vez por trimestre, la diferencia en la experiencia del cliente es real, aunque el panel muestre un conjunto completo.
Tampoco es algo que resuelva la traducción automática sin revisión - acelera la primera versión, pero no comprueba si esa versión sigue describiendo el producto real seis meses después.
Resumen
Una base de conocimiento multilingüe no se desincroniza porque alguien tradujera mal - se desincroniza porque un cambio en un sitio no tiene forma de llegar a los otros cinco. Vincular versiones, mantener un idioma de origen claro y revisar solo lo que realmente cambió cuesta menos que una sola conversación de soporte con un cliente que llegó a una respuesta desactualizada.