Localizar campañas de correo electrónico en varias regiones solía ser una tarea lenta y repetitiva con muchos pasos manuales.Múltiples revisores trabajaron en versiones separadas, el mismo contenido fue reescrito varias veces, y gestionar la coherencia en hasta 13 idiomas requirió una coordinación significativa. En lugar de introducir nuevas plataformas o herramientas externas, realizé un experimento interno: Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? El prototipo se basó principalmente en SharePoint, Power Automate y Teams, con un componente adicional - GPT-4.1 mini accesible a través de Azure OpenAI - usado estrictamente para un paso de QA controlado. Para soportar este flujo de trabajo, configuré una biblioteca estructurada de SharePoint llamada con carpetas que representan cada etapa del ciclo de vida de la localización: Email translations Folder Purpose 01_Incoming_EN Source English files; Power Automate trigger 02_AI_Drafts Auto-translated drafts from Copilot + GPT 03_In_Review Files waiting for regional review 04_Approved Final approved translations 99_Archive Archived or rejected versions 01_Incoming_EN Archivo de la etiqueta: power automatic trigger 02_AI_Drafts Desarrollos de traducción automática de Copilot + GPT 03_In_Review Archivos en espera de revisión regional 04_Approved Traducción final aprobada 99_Archive Versiones archivadas o rechazadas Los archivos se mueven automáticamente entre estas carpetas dependiendo de su estado. El objetivo no era construir un sistema de localización perfecto, sino ver hasta dónde podría llegar un prototipo utilizando herramientas internas. Terminó eliminando una gran parte del trabajo repetitivo y creó un proceso de revisión mucho más estructurado. The Problem: Process, Not Language El problema: el proceso, no el lenguaje Localizar el contenido manualmente en muchas regiones creó varios problemas consistentes: Cada región editó su propio archivo, por lo que varias versiones diferentes existieron al mismo tiempo. Cuando el texto fuente cambió, no todas las regiones actualizaron su versión, lo que llevó a contenidos que no coincidieron. Los archivos se guardaron en diferentes lugares y con diferentes nombres, lo que dificultaba identificar qué versión era actual. Las revisiones tomaron tiempo, especialmente cuando los equipos estaban en diferentes zonas horarias. Repetir las mismas ediciones en muchos archivos aumentó el riesgo de pequeños errores Attempt 1: Copilot-Only Translation Intento 1: Traducción solo por copiloto Aunque Copilot ahora se ejecuta en modelos más recientes de la serie GPT-5, este prototipo se construyó en una versión anterior, y el comportamiento de traducción reflejó esas capacidades anteriores. La primera versión del flujo de trabajo fue simple: Se ha cargado un archivo a 01_Incoming_EN. Power Automatic se activa automáticamente. Copilot generó una traducción para cada región. Debido a que los desencadenantes de SharePoint pueden dispararse antes de que un archivo finalice la carga, el flujo incluyó una verificación de tamaño de archivo (espera hasta que el tamaño > 0 antes de continuar). Sin embargo, el problema principal se aclaró rápidamente: las traducciones de Copilot no eran suficientemente fiables para la localización de fin a fin. Temas comunes incluyen: CTAs traducidos demasiado literalmente tone and style varying between languages Se eliminan o cambian los puestos Diferencias de formato en listas, espaciamiento y estructura Esto hizo que Copilot sólo fuera útil para generar un primer proyecto. Se necesitaba una segunda capa de control de calidad. Attempt 2: Adding GPT-4.1 Mini for QA Intento 2: Añadir GPT-4.1 Mini para QA La siguiente versión añadió un paso de revisión: Copilot → traducción inicial GPT-4.1 mini (Azure) → QA y comprobación de la consistencia GPT-4.1 mini mejorado: Tono de coherencia Preservación del lugar Formación de la estabilidad Alineación con el significado de la fuente Los prompts necesitaban ajuste para evitar la reescritura innecesaria, pero después de los ajustes, las salidas se convirtieron en lo suficientemente consistentes como para ser utilizadas en el flujo de trabajo. Engineering Work: Making the Workflow Reliable Trabajo de ingeniería: Hacer el flujo de trabajo fiable La arquitectura era simple, pero varios problemas aparecieron durante el uso real y necesitaban correcciones. Platform behaviour: Los desencadenantes de SharePoint no siempre se iniciaron de inmediato, por lo que se añadieron cheques y retries. Teams routing failed when channels were renamed, so the mapping had to be updated. Design issues: Algunos pasos paralelos fracasaron en la primera carrera, por lo que se introdujo la lógica de retry. Las respuestas de JSON a veces carecían de los campos esperados, por lo que se agregó la validación. Los nombres de archivos eran inconsistentes, por lo que se definió un único formato de nombramiento. Después de estos ajustes, el flujo de trabajo funcionó de forma fiable en condiciones normales. Final Prototype Architecture Arquitectura de prototipos finales A continuación se muestra la estructura completa del sistema. 1. SharePoint Upload & Intake El proceso comenzó cuando un archivo fue cargado en Email translations / 01_Incoming_EN La potencia automática es: comprobado que el archivo se ha cargado completamente (guardia de byte cero) Recuperación de metadatos Texto extraído Regiones de destino identificadas SharePoint actuó como la única fuente de verdad para todas las etapas. 2. Power Automate Orchestration Power Automate controló cada parte del flujo de trabajo: Leer la fuente inglesa Convocar al Copilot para el proyecto de traducción Enviar el proyecto a GPT-4.1 mini para QA Crear una sucursal por región E-mailing de salida a los equipos locales Cartas de aprobación de equipos Capturar “aprobar” o “solicitar cambios” guardar archivos aprobados en 04_Approved guardar versiones actualizadas en 03_In_Review archivo de versiones antiguas en 99_Archive Todos los enrutamientos, retiros y transiciones de estado fueron gestionados por Power Automate. 3. Copilot Translation Pass Copilot tradujo el contenido extraído y preservó la mayor parte de la estructura del correo electrónico - listas, espaciamiento y formatación - mejor que el GPT solo. 4. GPT-4.1 Mini QA Pass GPT-4.1 mini revisado por: Tono de coherencia Significado de alineación Formación de la estabilidad La integridad del lugar Esto creó un proyecto de revisión regional más fiable. 5. Regional Review (Email + Teams) Para cada región, Power Automate: Enviar el archivo traducido por correo electrónico Publicó una tarjeta adaptativa de Teams con cambios de aprobación / solicitud Si se enviaron cambios, el archivo actualizado se devolvió a Volver a entrar en el flujo de trabajo. 03_In_Review 6. Final Storage Las traducciones aprobadas se almacenan en Usar un formato de nombramiento consistente. 04_Approved Las versiones rechazadas o desactualizadas se han trasladado a Esto garantizó una pista de auditoría completa y limpia. 99_Archive. Results Resultados Después de probar el prototipo en flujos de trabajo reales: El tiempo de traducción se reduce de días a minutos Menos conflictos de versiones Redacción manual mínima Ciclos de revisión más rápidos Todos los datos procesados dentro del entorno de Microsoft Esto no reemplazó a los sistemas de localización dedicados, pero eliminó una cantidad significativa de trabajo manual repetitivo. Limitations Limitaciones Algunos idiomas aún requieren ajustes estilísticos Las aprobaciones de los equipos dependen de los tiempos de respuesta de los revisores El flujo necesitaba la lógica de retry para errores transitorios Consistencia de tono variable en correos electrónicos largos o complejos Estos eran aceptables para un prototipo. Next Step: Terminology Memory Siguiente Entrada siguiente: Memoria terminológica La próxima mejora planificada es una biblioteca de terminología basada en vectores que contiene: Glosario Nombres de productos Términos restringidos Frases específicas de la región Grupos sinónimos Reglas de Tono Ambos modelos usarían esta biblioteca antes de producir o comprobar traducciones. Final Thoughts Pensamientos finales Este proyecto fue un experimento interno para comprender cuánto del flujo de trabajo de localización se podía automatizar usando solo herramientas estándar de Microsoft y un LLM alojado en Azure. No es una plataforma de localización completa, pero muestra lo que se puede lograr con un flujo de trabajo simple y bien estructurado dentro de la pila empresarial existente.
