Internacionalización de Frontend Que Se Lee Como Inglés (Gracias, gettext!)

Hola a todos. Espero que estén disfrutando del React Summit US. Hoy, voy a compartir sobre una metodología de internacionalización frontend que he estado usando en mi proyecto que me gusta mucho y me gustaría compartir más con todos. Se lee como inglés. Puedes decir por el título, probablemente se trata de gettext, pero déjame entrar en más detalles. Primero que nada, un poco sobre mí. Mi nombre es Henry Lee. Actualmente soy líder técnico en Henge. Un dato curioso sobre mí, me gustan los teclados, los teclados ergonómicos. Realmente me gusta construir mi propio teclado. Y también, uso NeoVim. Y un poco sobre mi empresa, mi empresa es Henge. Estamos construyendo soluciones de seguridad en la nube B2B en Japón. Y si estás interesado en trabajos de ingeniería de software en Japón, revisa este enlace.

Con eso fuera del camino, comencemos con el estado de I18N frontend. Entonces, si estás construyendo un proyecto de React y quieres agregar internacionalización, esa es una palabra bastante larga. Esto es lo que normalmente harías. Instalas una biblioteca basada en JSON, React I18N, React Intel. Preparas traducciones como archivo de diccionario JSON, y luego cargas esas traducciones en tiempo de ejecución y reemplazas la clave en tu código con el valor que está en el diccionario. Este es cómo se ve el archivo de diccionario para un proyecto con inglés y japonés. Creas tu propio nombre de clave, como welcome, description. Y tienes la versión en inglés y la versión en japonés aquí. Así que se ve bien. Se ve simple. Funciona bien. Pero, ¿es realmente tan simple? Este flujo de trabajo está fundamentalmente roto de alguna manera. Déjame entrar en más detalles. Así que el primero. Nombrar claves es difícil. Como ingenieros, sabemos que escribir código es nuestro trabajo e inventar nombres de variables no es tan fácil como parece.

Hay dos problemas difíciles en la informática, la infiltración de caché, nombrar cosas y errores de desbordamiento. Nombrar cosas es una de las cosas que los ingenieros siempre encontramos desafiantes. El primero es la carga cognitiva. Si tenemos una estructura de diccionario JSON, ¿qué tipo de estructura de nombres queremos? ¿Debería estar categorizado por página, pages.buttons.save? ¿O debería estar categorizado por la característica dentro de cada página, así page.createUserForm.save? ¿O debería incluso ser extraído en su propio grupo, como common.buttons.save? Estas son cargas cognitivas con las que tenemos que lidiar. Esto también es propenso a ser inconsistente. Por ejemplo, tenemos un esquema de nombres, estamos de acuerdo con él, pero luego como que olvidamos en un minuto como, ¿cuál era de nuevo? ¿Es buttons.save o es como undercommon.buttons.save? Esos son los dolores de nombrar cosas. El segundo es que el contexto se pierde cuando estás usando un diccionario JSON. Con el diccionario JSON, los traductores necesitan entender cómo estructuras tu aplicación y luego inferir desde allí. Como ejemplo, si tenemos este archivo de traducción para un juego, tenemos como dos claves que se llaman save. Una está dentro de acciones de usuario y la otra está justo arriba. El traductor al no conocer el contexto, adivinaría, está bien, ambos significan lo mismo. Quieren guardar los cambios como en un formulario. Así que eligen en este caso, la palabra japonesa, hōzōn. Pero por ejemplo, en este caso, la aplicación podría significar una cosa diferente. Como lo que quieres bajo acciones de usuario. Guardar no es para guardar cambios en un formulario, sino como para rescatar a una persona en el juego, porque esto es como una traducción de juego. Así que las traducciones deberían ser diferentes, pero el traductor necesita saber que esto es diferente solo leyendo las claves, lo cual no es muy intuitivo.

El tercero es la duplicación de palabras. Es fácil hacer accidentalmente traducciones duplicadas a través de diferentes claves. Como ejemplo aquí, podemos tener como un botón de modelo, acción de formulario, perfil de usuario. Haríamos diferentes claves como si las agrupamos por características, haríamos diferentes claves que básicamente necesitan la misma palabra exacta. Y en este caso, podemos ver que hay muchas duplicaciones, pero algunas personas podrían decir, podemos simplemente extraer a un grupo común. Como cancelar es una palabra muy comúnmente usada. Y eso es cierto, pero eso es más cognitivo. Como cuándo empiezas a extraer estas palabras? ¿Empiezas cuando encuentras la primera duplicación? ¿Es demasiado trabajo? ¿Empiezas desde la segunda duplicación? Tienes que verificar manualmente y extraerlas. Tienes que recordar usar la clave común la próxima vez. Si olvidas que ya has extraído, podrías accidentalmente usar la clave existente.

La cuarta cosa son las traducciones obsoletas. Digamos que después de desarrollar tu proyecto por un año, la estructura de claves ha cambiado. Quieres refactorizar la clave de una a otra.

Quieres refactorizar la clave de una a otra. ¿Qué pasa con la clave antigua? Algunas personas dirían que es demasiado arriesgado intentar eliminar la antigua clave. La aplicación puede romperse. Puede ser utilizada accidentalmente en algún lugar donde no se suponía que debía estar. Eliminar la clave también significará que estamos eliminando la traducción. Podrías realmente querer mantenerla solo como referencia para futuras traducciones, o simplemente puedes dejarla allí, lo cual es como acumular deuda técnica. Obtienes más trabajo para los traductores, más carga cognitiva, y también se suma al tamaño final del paquete.

Además, ¿qué pasa si un recién llegado se une al equipo? Tienen que aprender sobre la estructura de claves. Tienen que revisar estos archivos de diccionario masivos que tienes. Y encuentran estructuras conflictivas. Como una página usa esta metodología. Otra página usa otra. Es bastante confuso. Algunas de estas claves ni siquiera se usan más. Como algunas páginas ya están eliminadas, pero las claves aún permanecen en el archivo. ¿Qué pasaría si pudiéramos evitar todos estos dolores? Dejar de inventar nombres de claves. Simplemente escribimos inglés en el código. Eso sería ideal, ¿verdad? Como simplemente escribir inglés, y puedes, cuando estás codificando, cuando estás leyendo el código, sabes exactamente qué palabra se muestra en ese elemento.

¿Y si la herramienta también pudiera extraer mensajes automáticamente para que no tengas que llenar el JSON a mano? Y luego puedes dejar que los traductores trabajen con mensajes reales en lugar de con claves abstractas que definimos como programadores. Así que hay una herramienta que hace exactamente eso. Y esta no es de la herramienta. La herramienta se llama GNU GetTex. GetTex es una de las herramientas que se utiliza en GNU, un conjunto de aplicaciones que se usa comúnmente en sistemas operativos Linux. Este es el icono de GNU en sí. GetTex es un paquete muy, muy popular que se utiliza desde tan temprano como 1995 en el proyecto GNU. Está impulsando las traducciones de todo el ecosistema Linux desde las utilidades CLI del núcleo hasta los entornos de escritorio. Es un estándar no solo en el entorno Linux, sino también en marcos web y lenguajes como Python, PHP, WordPress. Todos usamos comúnmente GetTex para traducciones. La idea central aquí es que tu código fuente es la única fuente de verdad. Lo que eso significa es que en este caso, si escribes un mensaje traducido como una cadena en inglés en tu código, será extraído como un diccionario.

Y así es como se ve el diccionario. Obtienes el ID del mensaje, que es como el idioma fuente, el mensaje traducido y luego la cadena del mensaje, que es lo que será la traducción para el idioma respectivo que deseas. Luego, la herramienta de extracción también puede informarte dónde se utiliza en la base de código. En este caso, solo se usa en un archivo, app.js en la línea 3. También puede listar todos los archivos que están usando esta cadena específica. También puede extraer automáticamente comentarios para los traductores. También puede marcar cadenas como obsoletas si ya no se utilizan en ningún lugar del proyecto. Esto no debería tener ninguna referencia aquí si está obsoleto.

El flujo de trabajo de GetTex es así. Entonces, primero que todo, tenemos el código fuente. En este caso, es C. Usamos xGetTex para crear un archivo de plantilla de objeto portátil. A partir del archivo de plantilla, usamos message init para crear archivos de diferentes idiomas. Y luego, si tenemos algún cambio nuevo en el archivo de plantilla, usaremos message merge, que es como fusionar la nueva plantilla con el archivo TO existente. Y luego usamos message format para generar el objeto de máquina a partir de nuestro objeto portátil. Y este objeto de máquina es el código de bajo nivel que se utiliza en nuestra aplicación según el idioma.

Cuando ves este flujo de trabajo, podrías pensar, oye, eso parece muy complicado. La buena noticia es que no tenemos que usar ese flujo de trabajo complicado en nuestro proyecto. Así que hay muchas herramientas que nos permiten usar el flujo de trabajo de GetTex en frontend. Pero creo que Lingui es una de las cosas que he usado. Y creo que proporciona una muy buena DX. Así que Lingui es una implementación de GetTex muy popular, no solo para React sino también para JavaScript puro. Es una herramienta CLI que simplifica la extracción de mensajes, la gestión de catálogos de mensajes, la compilación de traducciones. No necesitamos lidiar con cada una de las herramientas de GetTex que expliqué anteriormente para seguir todo el flujo. Con Lingui, podemos hacer algo como esto. En lugar de escribir el nombre de la clave en nuestro código y luego proporcionar las variables según sea necesario, podemos simplemente decir, usemos la palabra en inglés aquí. Así que en este caso, usa hello en lugar de la clave greeting. Escribimos hi, user. Hi, username. You have count new messages.

En lugar de simplemente escribir una clave aquí, y luego tener la referencia al diccionario, ¿qué debería representar esta clave? Puedes simplemente escribir en inglés aquí y obtener el contexto completo de lo que se supone que debe mostrar este elemento h2. Y este es el flujo de trabajo con Lingui.

Primero, definimos mensajes, ya sea llamándolo con la función T como antes o con el componente trans. Ejecutamos el comando extract de la CLI para generar el catálogo, el diccionario. Y luego añadimos traducciones a este archivo, ya sea haciéndolo manualmente, usando IA o herramientas o servicios de IA para editar o enviarlo a nuestros traductores.

El archivo PO es un estándar comúnmente conocido con el que los traductores deberían estar familiarizados. Además, luego ejecutamos compile después de haber estado en las traducciones. Y después de generar el archivo de paquete final, lo desplegamos junto con nuestra aplicación.

Así que este es un ejemplo de cómo definimos mensajes. Usamos la función auxiliar T, y esta es la función literal de plantilla de etiqueta. Así que es como llamar a la función T con un parámetro string llamado hello world. Pero esto es solo un poco más conciso. Si necesitamos usar un nombre de variable, podemos simplemente usar la plantilla literal de etiqueta, el parámetro de la plantilla literal de etiqueta. Así que simplemente parametrizamos esto y usamos el nombre de la variable. Muy simple.

Una cosa a tener en cuenta es que Lingui analiza estáticamente nuestro código e intenta encontrar qué cadenas necesitan ser traducidas. Así que no podría encontrar cadenas que se evalúan como resultado de una expresión. En este caso, tenemos una función que devuelve la cadena even o odd. Si simplemente la usamos aquí dentro de T, entonces Lingui no sabría que necesitamos extraer even y odd porque no ejecuta tu código y encuentra qué cadenas se están importando. Lo que deberíamos hacer en su lugar es marcar cada cadena que necesita ser traducida de antemano con la función auxiliar llamada msg aquí para mensaje. Y luego simplemente usamos T en la función evaluada. Y con esto, el proceso de extracción funciona y la traducción en tiempo de ejecución también funciona como se espera.

Este es un ejemplo del resultado que veremos cuando ejecutemos el comando de extracción. Cuando llamamos a Lingui extract, recorrerá toda nuestra configuración, generará los archivos según sea necesario. En este caso, tengo dos idiomas configurados, inglés y japonés. Me muestra que encontró como 22 mensajes que necesitan ser traducidos. Y dado que el inglés es la fuente, no hay traducción faltante. La clave es en realidad el mensaje de traducción. Pero para el japonés, dice que tengo siete traducciones faltantes. Eso significa que necesito ir al código y ver qué falta y añadir esas traducciones o solicitar traducir o usar IA. Así que es muy simple, es muy intuitivo. Nos muestra exactamente lo que necesitamos en mucho detalle. Y así es como se ve el catálogo de mensajes. Como se mencionó un poco antes, tenemos el ID HelloWorld, myName is name. Es lo suficientemente inteligente como para decir que estamos usando una variable llamada name aquí. Si es una expresión más compleja, no funcionaría. Pero para simplemente llamar a la variable podrá inferir el nombre aquí. Solo necesitamos completar las traducciones en este campo de cadena de mensaje.

Como se mencionó, podemos simplemente editar el archivo, solo una traducción o simplemente enviarlo al traductor. Y así es como se ve el resultado compilado. Por ejemplo, en este caso, estoy exportando un archivo de JavaScript. Perdón, un archivo de TypeScript. Hay un tipo de importación aquí. Y como puedes ver aquí, realmente no estamos usando la palabra en inglés real, la clave, el mensaje como clave en el resultado compilado para ahorrar en el tamaño del paquete. En lugar de usar una cadena potencialmente muy larga, Linguin hará un hash de la cadena que usamos, la hará muy pequeña, la hará muy simple para que no, para que el tamaño del paquete se mantenga pequeño.

Esto es un DX ambiguamente mejor. Eliminamos la necesidad de gestionar claves, de determinar claves, no hay entradas duplicadas, porque la cadena en sí es la clave. Tenemos el contexto completo para los traductores. No necesitan adivinar qué significa la estructura de datos. Pueden simplemente ver en el diccionario que, oh, esta es la palabra que necesito traducir. Y siempre está sincronizado con extraer y compilar. Extraer siempre se referirá a tu código fuente como la única fuente de verdad.

Así que tu extracción, tu archivo PO nunca estará desactualizado mientras los extraigas regularmente. Para los traductores, también es bueno que no tengan que entender la estructura de claves arbitraria. El archivo PO es un estándar de la industria. Los traductores saben cómo manejarlo, y pueden centrarse en lo que más importa, que es el texto fuente y hacer las traducciones. Podrías pensar, ¿qué pasa con las cosas complejas? ¿Linguin lo hace bien? Sí. Como ejemplo aquí, si tengo la palabra en inglés right, que puede tener al menos dos significados diferentes.

Right, como en girar a la derecha o girar a la izquierda. O right, como en correcto, estás en lo correcto. En este caso, podemos usar la función T, pasando un objeto, mensaje y contexto. El contexto aquí permitirá al traductor saber a qué right nos referimos. Y dentro del catálogo, se mostrará como el contexto del mensaje aquí. Así que cuando los traductores vean esto, sabrán, oh, esta es la traducción que debo hacer para esta palabra en particular.

También hay comentarios, si quieres escribir, explicar en qué contexto se está utilizando este mensaje. Puedes simplemente escribir el comentario aquí, y aparecerá en el diccionario también. Los plurales también son muy comunes, se manejan de manera muy simple. Y lo bueno de Linguin es que no solo utiliza getTextPlurals, que es ligeramente menos flexible, sino que admite la sintaxis de mensajes ICU, que es mucho más flexible. Por ejemplo, el inglés tiene una regla muy simple para los plurales, uno o cualquier cosa que no sea uno.

Así que un ítem, dos ítems, cero ítems, y así sucesivamente. Así que en el archivo del diccionario, esto es también lo que escribes, llamado plural. Defines para cada variación qué traducción debería ser. Si estás traduciendo al japonés, no tienen plural, así que está bien. Si estás traduciendo a otros idiomas que tienen reglas plurales más complejas como uno, dos, tres, cuatro diferentes, simplemente lo defines aquí. Así que es muy flexible. Puede manejar todos los idiomas que tienen diferentes reglas plurales. También hay muchas otras características como select para enums, puedes interpolar HTML o componentes dentro de él, muchas cosas que Linguin ha manejado.

Así que tu próxima pregunta sería algo así como, ¿por qué no todos están usando esto? Si es tan bueno, ¿por qué no es popular? Y creo que esto es porque el default, como React-IoT-Next, React-Intel, son como las bibliotecas predeterminadas que muchos conocen. Es como el estándar de facto. Cuando haces una búsqueda en Google, ¿cómo agrego IoT y hago una aplicación en React? Cuando haces LLM, Azure, SGPT, esa también es la primera respuesta que aparece. Así que no hay incentivo para realmente buscar una mejor manera cuando el enfoque común funciona lo suficientemente bien. Y algunos equipos también tienen miedo de agregar un paso de construcción. En lugar de agregar un paso de construcción, déjame hacerlo manualmente. No quiero que las cosas sean demasiado complejas. Pero el front-end en sí inherentemente tiene un paso de construcción. Así que esto solo está agregando un poco más para mucha conveniencia del desarrollador. Además, algunas personas simplemente no son conscientes de que esto existe. Que este enfoque es una cosa. Si comienzan con la web, no tienen experiencia previa con nuevos Unix. Creo que no son conscientes de que esto es una cosa. Así que esto es algo que más exposición ayudará. O artículos como historias de éxito, personas que lo han usado con éxito podrán usarlo bien. Así que mi llamado a la acción es que si estás trabajando en un nuevo proyecto, considera usar Lingui, pruébalo, ve cómo funciona. Creo que la DX es mucho mejor que las alternativas existentes. Si estás manteniendo un proyecto existente, puedes comenzar a discutir si vale la pena migrar a este enfoque. Puede que no valga la pena, dependiendo del tamaño del proyecto y los recursos. Pero podría ser algo a considerar. Comparte la existencia de esta herramienta, discute con tu comunidad, discute con tus equipos si esto realmente va a ser una buena opción para ti. Y sí, eso es todo de mi parte. Gracias por escuchar. Aquí están mis diapositivas y mis redes sociales. Muchas gracias. Disfruta el resto del React Summit US.