¡Cómo Soporto Más de 100 Idiomas en Mi App de React...y Tú También Puedes!

Soy Richard Kerrigan, y estoy emocionado de estar aquí hoy para mostrarte cómo puedes agregar soporte multilingüe a tus aplicaciones de React. Antes de sumergirnos en el tema de hoy, permíteme hacer algunos anuncios rápidos. Problema número uno, aunque trabajo en Microsoft, de ninguna manera estoy afiliado al equipo de Azure AI, ni estoy buscando convencerte de adoptar Azure como tu proveedor de servicios en la nube. Como verás al final de esta charla, mi objetivo es demostrar una posible solución para traducir automáticamente el contenido de aplicaciones web de sitios web a otros idiomas y dialectos, pero absolutamente podrías construir algo similar usando AWS, GCP, u otro proveedor de servicios en la nube que ofrezca un servicio de traducción de documentos.

Punto número dos, ya existen bibliotecas, como React, IATN, que te permiten traducir contenido estático, como el encabezado de tu página de inicio, pie de página, etc., a otros idiomas usando las traducciones que proporcionas.

Las soluciones que te presentaré hoy son para traducir automáticamente el contenido dinámico, como publicaciones de blog creadas por los creadores de contenido de tu equipo o incluso por los usuarios finales. Muy bien, con esos anuncios fuera del camino, vamos a sumergirnos. Primero, establezcamos claramente el problema que estamos tratando de resolver. El problema que estamos tratando de resolver es que la mayoría de los sitios web, aplicaciones web, solo publican contenido en un idioma, lo cual no es conveniente para los usuarios y no es inclusivo para las personas para quienes ese idioma no es su idioma principal.

Ahora hay varias formas en que podríamos abordar la solución del problema, dependiendo de los recursos que tengamos disponibles. Pero para el propósito de esta charla, supongamos que no tenemos mucho presupuesto para dedicar a esta función, ni tenemos un equipo que pueda traducir contenido para nosotros. Así que nuestra solución debe ser de bajo costo y requerir interacción humana solo para validar los resultados.

Este es un caso de uso fantástico para la IA y la automatización. Cuando mi equipo comenzó a abordar este problema, por razones obvias miramos primero a Azure. A través de esa investigación, encontré el servicio de traductor de Azure AI. Este servicio no solo permite la traducción de texto ad hoc, donde envías texto directamente a través del traductor y devuelve el texto traducido como JSON, sino que también ofrece traducción de documentos, que toma como entrada uno o más archivos de un contenedor de almacenamiento de blobs, los traduce y produce los archivos traducidos en un contenedor de almacenamiento de blobs diferente.

Además, el servicio de traductor de Azure AI tiene algunas características clave que finalmente nos convencieron de que era la opción adecuada para nuestras necesidades. La primera característica clave que fue importante para nosotros fue el soporte de idiomas. Mi equipo en Microsoft ejecuta un programa de mejora de habilidades y recapacitación que opera en todo el mundo. Por lo tanto, es importante para nosotros que cualquier solución multilingüe pueda acomodar cualquier idioma o dialecto que queramos soportar. Con más de 100 idiomas y dialectos diferentes soportados, incluso incluyendo Klingon, el traductor de Azure AI fue definitivamente la elección correcta para nosotros.

La siguiente característica clave para nosotros fue el costo. El traductor de Azure AI tiene un nivel gratuito generoso de hasta 2 millones de caracteres traducidos por mes. Así que dependiendo de la cantidad de contenido en tu sitio y con qué frecuencia traduces tu contenido, es posible que ni siquiera incurras en un costo. Otra característica importante es la precisión. El traductor de Azure AI utiliza lo que llaman Traducción Automática Neuronal o NMT, que en sus propias palabras es una mejora sobre los enfoques anteriores de traducción automática estadística, SMT, ya que utiliza muchas más dimensiones para representar tokens, como palabras, morfemas y puntuación del texto fuente y objetivo. Además, explican que usando el enfoque NMT, la traducción tomará en contexto la oración completa en lugar de solo unas pocas palabras en una ventana deslizante que utiliza SMT y producirá traducciones más fluidas y con apariencia de traducción humana. Para nosotros, esto significa traducciones más contextualmente precisas, lo que significa menos ajustes, si es que se necesitarían. Esto es lo que hace posible para nosotros integrar traducciones en nuestro flujo de trabajo CI CD.

La última característica clave para nosotros es la capacidad de usar glosarios personalizados para ajustar el proceso de traducción, lo cual es útil para omitir la traducción de terminología específica de la industria y/o texto relacionado con la marca, así como para asegurar que ciertas palabras o frases se traduzcan de una manera que retenga el significado original. No todo es color de rosa, así que también quería tomar un momento para señalar algunas de las limitaciones del traductor de Azure AI. Aunque el servicio puede manejar muchos tipos de archivos diferentes, actualmente no puede manejar MDX o JSX TSX, por lo que tu contenido necesitará ser almacenado por separado de estos archivos para ser traducido. Otra limitación es que todas las respuestas de traducción se devuelven como texto horizontal, de izquierda a derecha o de derecha a izquierda, por lo que es posible que necesites agregar lógica de renderizado si deseas mostrar contenido en un formato vertical para los idiomas aplicables. Finalmente, como con cualquier implementación de IA, aún querrás validar los resultados antes de desplegarlos en producción, y es posible que encuentres que se necesiten ajustes adicionales, lo que también requeriría un nuevo despliegue y revalidación.

Bien, suficiente charla sobre el traductor de Azure AI, vamos a entrar en cómo vamos a diseñar este flujo de trabajo. Dependiendo de cómo se almacene el contenido, hay esencialmente tres opciones para cómo traducirlo. Opción 1, tu contenido se almacena como JSON. Como puedes ver en este fragmento de JSON, tenemos un array de publicaciones, que son objetos que contienen los diversos datos que nuestro frontend necesitaría para renderizar cada publicación. Si tu contenido se almacena de esta manera, lo más probable es que desees traducir el contenido durante el tiempo de ejecución usando la API de Azure Translator, probablemente usando un componente de servidor de React o una API personalizada separada que almacenaría en caché el contenido traducido para reducir la frecuencia con la que se ejecuta el servicio de traducción, lo que en última instancia mantendrá tus costos bajos.

Aquí tienes un ejemplo de cómo podrías lograr esto. Como puedes ver, estamos tomando solo las piezas de datos que necesitan ser traducidas, a saber, el título, el extracto y el contenido, y enviando cada pieza a través del traductor. Luego, una vez que tenemos todo el contenido traducido, lo enviamos como respuesta. Este ejemplo podría añadirse a un componente de servidor de React o a una ruta de API existente que envíe el contenido a la aplicación React.

Escenarios 2 y 3, tu contenido se almacena como archivos HTML o Markdown separados. En cualquiera de estos casos, en lugar de ejecutar la traducción en tiempo de ejecución, podemos realmente incorporar el proceso de traducción en nuestro flujo de trabajo CI-CD. Primero, necesitaremos subir los archivos a traducir a un contenedor de Azure Blob Storage. Luego, necesitaremos crear y luego activar una Azure Function App o similar que orqueste el proceso de traducción, incluyendo especificar los idiomas de entrada y salida y los contenedores correspondientes de Blob Storage. Una vez que la función app ha completado, entonces necesitamos descargar los archivos traducidos del contenedor de salida de Blob Storage y añadirlos a los archivos de código fuente de la aplicación. Finalmente, estamos listos para desplegar nuestra aplicación React. Querrás asegurarte de desplegar la aplicación en un entorno de prueba primero para que puedas validar el resultado de la traducción antes de desplegar en producción.

Muy bien, suficiente hablar sobre conceptos. Veamos algo de código. Primero, vamos a recorrer cómo se ve la solución para contenido JSON traducido en tiempo de ejecución. Así que, aquí, si miramos la ruta de API para mi aplicación Next.js, verás que hay esta función de traducción, tal como vimos antes en las diapositivas. Si profundizamos en esa función de traducción, verás que es esencialmente solo una llamada API post yendo a Microsoft Translator. Lo que estamos haciendo es tomar la configuración regional que se solicitó. Puedes pensar en esto como la ruta siendo el dominio del sitio web y luego barra en-us o es-es para español o similar a eso. Estamos tomando solo la primera parte de eso, así que como el en o el es, para entender a qué idioma están tratando de traducir. Y luego estamos juntando eso con el endpoint de la API, y estamos especificando eso como el idioma de destino. Y luego aquí, estamos enviando esta solicitud post a nuestro servicio de traducción, y estamos enviando el texto en forma JSON. Y luego, una vez que la traducción regresa, entonces estamos profundizando en ese JSON y tomando solo la traducción de texto de él y enviándola como respuesta. Así que esa es la solución para traducir JSON.

A continuación, veamos cómo traduciríamos archivos HTML desde dentro de un pipeline CICD. Así que cambiaré a mi rama de markdown. Lo siento, mi rama de HTML. Muy bien. Así que mirando esta misma ruta de API, lo principal que vas a ver es que ya no estamos haciendo ningún trabajo de traducción dentro de la ruta de API. Puedes ver que estamos analizando a través del head y tomando los datos de allí, pero eso es todo.

En su lugar, lo que hemos hecho es trasladarlo a nuestro flujo de trabajo de GitHub Actions. Así que si lo abro y empiezo desde arriba, lo que estamos haciendo es pasar por aquí y primero estamos creando todos los recursos en Azure. Y si miramos en la plantilla para eso, verás que tenemos la static web app para el sitio de Next.js, App Insights vinculado a ella para que podamos recopilar telemetría. Y luego tenemos nuestra function app que va a realizar el proceso de traducción. Y luego tenemos nuestro servicio de traducción. Y luego tenemos nuestra cuenta de almacenamiento, que contiene un contenedor de archivos de entrada y un contenedor de archivos de salida.

Así que volvamos a nuestro flujo de trabajo de GitHub. Entonces, después de provisionar todos estos recursos, construimos nuestra function app dentro del flujo de trabajo. Y luego, una vez que está construida, la desplegamos. Y luego, después de que esto se despliega, realizamos el proceso de traducción. Y si miramos en nuestra función real. Así que aquí es donde esencialmente ocurre toda la magia. Así que aquí solo estamos configurando todo. Esto no es realmente diferente de lo que harías cada vez que interactúas con blob storage. Pero luego aquí es donde empieza a ponerse más interesante. Así que estamos especificando el endpoint de traducción al que vamos a enfrentarnos. Y una cosa a destacar es que el endpoint de traducción cuando estás haciendo traducción de documentos es muy diferente del endpoint de traducción que vas a usar solo para texto como JSON. Y por eso quieres asegurarte de no usar el mismo dominio para cada uno de ellos. Y así aquí, estamos especificando nuestro glosario que nos permite ajustar nuestras traducciones. Y luego estamos pasando por cada uno de los archivos blob que están en nuestra entrada. Y aquí es donde configuramos cómo hacemos la traducción cuando vamos a ejecutar.

Así que estamos diciendo que queremos traducir al español y que le estamos proporcionando un glosario que está en formato CSV y que estamos haciendo traducción de archivos. Y luego enviamos nuestra solicitud y luego enviamos esos datos allí. Y luego, una vez que está hecho, entonces procedemos y creamos el nuevo blob dentro de nuestra ubicación de salida. Y luego solo estamos verificando para asegurarnos de que todo se haya hecho hasta que podamos cerrar esto. Y esto es necesario porque queremos que nuestro flujo de trabajo de GitHub espere hasta que todas las traducciones se hayan hecho antes de que continúe con el siguiente paso. Porque en el siguiente paso, después de ejecutar la traducción, estamos subiendo ese artefacto y luego descargándolo en la siguiente etapa. Y estamos tomando ese artefacto y lo estamos subiendo como nuestro próximo JSF. Y por eso es realmente importante que todas las traducciones se hagan primero, porque de lo contrario podrías terminar en una situación donde tienes la mitad de tu contenido traducido y vas a desplegarlo. Y entonces, cuando alguien cambia a ese idioma, ve la mitad de tu contenido y obtiene errores para la otra mitad porque el archivo no se encuentra.

Honestamente, cuando configuré esto por primera vez, se sintió como magia. Porque esencialmente estás enviando una solicitud al traductor y luego mágicamente obtienes este archivo traducido, y todo está bien. Y solo tienes que hacer un pequeño ajuste.

Así que finalmente, veamos cómo haríamos esta misma canalización de traducción pero para contenido Markdown en su lugar. Así que la canalización se mantiene exactamente igual. No hay diferencia aquí. Todavía estamos subiendo los archivos, activando la traducción, y luego obteniendo los archivos de salida y desplegando nuestra app. Así que no necesitamos entrar en eso de nuevo.

Y si miramos nuestro contenido traducido, aquí es donde es un poco diferente. Así que aquí, si bajo... Todo esto es lo mismo. Nada ha cambiado aún. Sí, déjame comparar esto rápidamente. Déjame volver a mi HTML para que puedas ver cómo se ve eso primero. Sí, aquí está la gran diferencia. Con HTML, porque toda la metadata para cada uno de estos posts se almacena en el head del archivo, así que si miramos uno de estos archivos, ves que tenemos nuestro título aquí, nuestro extracto, y luego al final tenemos todo nuestro contenido.

Y queremos traducir esto. Bueno, por defecto, cuando envías un archivo HTML, no va a traducir el head. Y por lo tanto, eso tiene que ser parte de nuestro proceso. Así que dentro de nuestra función, ves aquí que estamos analizando el documento y esto es después de que la traducción se ha hecho. Así que estamos tomando el archivo traducido y lo estamos analizando. Y luego lo que estamos haciendo es recorrer el head para obtener todas las metatags y luego estamos buscando específicamente el título y el extracto. Y una vez que lo encontramos, lo enviamos a través de nuestra función de traducción para obtenerlo traducido al idioma de destino. Y luego, después de que todo eso está hecho, estamos reensamblando nuestro head, incluyendo esa metadata traducida, y luego estamos reemplazando el archivo traducido con el nuevo archivo traducido que también tiene un head traducido.

Así que si volvemos a nuestra versión de Markdown, aquí es donde es bastante diferente. Porque aquí, después de hacer la traducción inicial, verás que no tenemos un segundo paso de necesitar traducir el head. Sin embargo, lo que sí tenemos es que tenemos que traducir la... todavía tenemos que traducir la metadata por separado. Y esto es en realidad un problema que encontré con Azure AI Translator, donde intenta traducir el front matter. Así que si miramos uno de estos posts, toda esta sección, si no estás familiarizado, toda esta sección es metadata en nuestro archivo Markdown. Así que intenta traducirlo, pero he encontrado varios problemas. Así que he encontrado problemas donde este punto se mueve fuera de la comilla, lo que evitará que este archivo se cargue. Y también he encontrado problemas donde intenta traducir algunas de las claves en los objetos. Y luego también intenta traducir algunas de las palabras en la ruta de la URL en sí. Y así, esto obviamente causa que todo se rompa. Y así, en nuestra función de traducción, es una configuración interesante. Así que tenemos que traducir no los archivos de destino, así que como los archivos traducidos, el front matter, porque en realidad es inanalizable ahora mismo debido a algunos de los problemas. Así que lo que realmente tenemos que hacer es analizar y luego traducir la metadata de los archivos originales y luego poner esa metadata traducida con el contenido de los archivos traducidos para que coincida. Y eso es lo que estás viendo aquí, donde estamos reemplazando o usando regex para encontrar el front matter y lo estamos reemplazando con la metadata traducida de los archivos de entrada. Y luego después de eso, luego estamos subiendo. Y así, así es como todo funciona. Así que ahora si saltamos a GitHub, podemos ver realmente el flujo de trabajo de GitHub actions ejecutándose. Y así aquí está la versión HTML. Y así ves primero aprovisionamos los recursos de Azure, luego construimos nuestra aplicación de función, luego la desplegamos. Luego ejecutamos nuestro proceso de traducción. Y luego con esos archivos traducidos, luego los desplegamos. Y de manera similar, ahora podemos entrar y podemos ejecutar esto para nuestra rama de markdown.

Y esto debería comenzar aquí en un segundo. Muy bien, ahí está. OK, y ahora está asegurándose de que haya un grupo de recursos en Azure para esto. Ahí vamos. Y ahora va a desplegar nuestra plantilla ARM que contiene todos los diversos recursos que vimos anteriormente.

Solo para recapitular lo que hemos discutido. El problema que estábamos tratando de resolver, que es el hecho de que muchos sitios web y aplicaciones web no ofrecen su contenido en idiomas adicionales. A continuación, discutimos los beneficios y características clave de Azure AI Translator. Pero también reconocimos que soluciones similares podrían construirse con otros servicios de traducción de proveedores de servicios en la nube. Finalmente, vimos las tres versiones diferentes de la misma aplicación, mostrando cómo traducir contenido JSON, HTML y markdown sin requerir que ningún miembro de tu equipo aprenda un nuevo idioma.

Siendo esta una sesión remota pregrabada, no puedo decirlo, pero sinceramente espero que estés tan entusiasmado con la solución como yo. Si deseas explorar estas soluciones con más profundidad, aquí está el enlace y el código QR al repositorio en GitHub, así como enlaces a un par de recursos para aprender más sobre Azure AI Translator.

Ahora volvamos a nuestro flujo de trabajo y veamos cómo está yendo. Bien, genial. Así que ha desplegado nuestros recursos de Azure. Ha construido nuestra función. Y ahora está en el proceso de desplegar eso. Y así, esta es la parte que realmente queremos ver, porque aquí es donde está traduciendo nuestros archivos markdown. Bien, así que en este punto, está descargando los archivos del almacenamiento blob. Y ahora ha activado la traducción. Y solo está esperando que el servicio de traducción diga que todos los trabajos han sido terminados. Y como decía antes, esta es una parte realmente importante, porque no quieres terminar sin que todos nuestros archivos estén traducidos cuando vayamos a desplegar después. Genial. Y así puedes ver aquí, incluso especifica cuántos archivos han sido traducidos.

Bien, y ahora está tomando estos archivos traducidos, poniéndolos de nuevo con el resto de nuestro código del repositorio. Y ahora estamos desplegando. Y solo una breve palabra sobre, como, infraestructura como código. Así que tengo esta configuración. De esa manera, garantiza que todos los recursos estarán allí. No necesariamente tienes que tener esa parte. Si quieres tener como un flujo de trabajo de acciones de GitHub separado, que despliegue tu aplicación de función, separado de la aplicación de NextJS, podrías hacerlo totalmente. Elegí hacerlo de esta manera, porque la aplicación de función es una dependencia de esta aplicación de NextJS. Y quiero asegurarme de que exista y esté configurada correctamente, antes de intentar ejecutar traducciones contra ella. Pero esa es solo mi preferencia personal.

Bien, así que lo ha desplegado. Y ahora solo está esperando que el servicio de aplicación web estática responda diciendo que la aplicación web estática está realmente lista para ser vista. Y esto toma alrededor de dos minutos. Y luego, una vez que esto esté hecho, podremos ver la aplicación completada. Bien, así que tomó un poco más de tiempo de lo esperado, pero nuestra aplicación web se desplegó. Así que vamos a abrirla y echarle un vistazo. Bien, aquí vamos. Así que tenemos nuestro blog, y tenemos diferentes publicaciones aquí.

Y para cada publicación, aquí es donde entra el título de los metadatos. Y luego este es el extracto de los metadatos. Tenemos otras publicaciones aquí abajo. Y si abrimos una de estas publicaciones, entonces ves, tenemos nuestro título nuevamente. Y luego tenemos nuestro markdown real siendo analizado en HTML para ser renderizado en el cliente. Y puedes ver que tenemos diferentes formatos. Así que, por ejemplo, tenemos encabezados, tenemos un enlace justo aquí, tenemos algo de texto en negrita, tenemos una lista desordenada.

Y luego si volvemos y cambiamos de idioma, ahora ves que el título ha sido traducido. El extracto ha sido traducido. Y es para todos estos. Y luego si abrimos una de estas publicaciones, ves que se ha mantenido el formato original. Así que, por ejemplo, nuestros encabezados todavía están ahí. Nuestro enlace sigue funcionando como se esperaba. El texto en negrita sigue siendo el mismo. Lista desordenada. Y todo se renderiza exactamente igual. Así que dejaré esto por un segundo.

Muy bien. Así que también, me encantaría escuchar sobre cualquier solución multilingüe que construyas basada en los conceptos que cubrimos hoy. Así que por favor, no dudes en conectarte conmigo en LinkedIn o X. Gracias a todos por asistir. Y espero que disfruten el resto de su conferencia.