Resolviendo i18n para Componentes de Servidor de React

Hola, soy Loris. Construyo herramientas de internacionalización en una empresa llamada Inlang, y hoy hablaré sobre la internacionalización para componentes del servidor. Entonces, para que todos estemos en la misma página, hablaré sobre las traducciones de cadenas, tus diseños, tus componentes, no tu contenido. Así que, cuando hacemos internacionalización, nuestro objetivo es, por supuesto, construir una aplicación multilingüe enviando la menor cantidad de bytes posible a través de la red. Queremos ser muy precisos en los mensajes y traducciones que cargamos para mostrar solo lo que es realmente necesario. Respetamos el ancho de banda de nuestros usuarios.

Antes de los componentes del servidor, la unidad en la que cargaríamos las traducciones era una página a la vez. Entonces, tendría un cierto conjunto de mensajes que necesitarías en una página, cierto conjunto de mensajes que necesitarías en otra página. Entonces, lo que harías es clasificarlos en espacios de nombres, grupos de nombres. Luego cargarías imperativamente estos espacios de nombres con algún tipo de función de carga de espacios de nombres. Cada elemento en una biblioteca va a tener algún tipo de equivalente a ese. Ahora, lo que normalmente terminarías teniendo es más o menos un espacio de nombres por página. Luego, si tienes un componente compartido por página, tal vez una barra de autenticación o un componente que se utiliza en muchas páginas, crearías un segundo espacio de nombres solo para eso. También lo cargarías imperativamente cuando cargas la página. Entonces, necesitas llevar un registro de, ok, ¿qué mensajes necesito exactamente y cuáles no necesito? A menudo también tienes algún tipo de espacio de nombres común donde tienes mensajes que se utilizan en muchos lugares diferentes, cosas genéricas, adelante, atrás. Entonces, lo que puedes ver aquí es que terminas teniendo bastantes espacios de nombres por página. Estoy seguro de que si has construido muchas aplicaciones multilingües, esto te resultará familiar. Pero hay bastante trabajo de contabilidad, pero por lo general es manejable. Terminas teniendo entre dos y cinco espacios de nombres por página. Es un poco de trabajo, pero se puede hacer. Pero este patrón se vuelve mucho más difícil de implementar correctamente si introduces componentes del servidor en la mezcla, porque la unidad en la que cargas los mensajes ya no es por página. Ahora estás tratando de cargar exactamente los mensajes que se necesitan para los componentes del cliente que vas a renderizar. Con los componentes del servidor, tu página es como una especie de parche de cosas que se renderizan en el servidor y cosas que están en el cliente, y necesitas mensajes en ambos, necesitas traducciones en ambos. Pero los requisitos sobre cómo cargar realmente estos mensajes son muy, muy diferentes. En el servidor, realmente no necesitas hacer ninguna carga detallada en absoluto. Puedes cargar todo, ser glotón y usar lo que quieras, como te gusta. No hagas ninguna contabilidad en absoluto. Eso es maravilloso. Pero si nos quedáramos con el enfoque de carga de espacios de nombres y carga imperativa, en el cliente, sería muy, muy doloroso, porque terminarías creando un espacio de nombres para cada componente del cliente, luego necesitarías cargarlo imperativamente con la página, y eso sería

ser mucho trabajo, mucha sobrecarga. Realmente solo queremos cargar los mensajes que se utilizan en una página y se utilizan en los componentes del cliente en esa página. Así que tenemos estos escenarios en competencia donde, por un lado, realmente necesitamos una carga muy, muy, muy detallada, y en el servidor, no necesitamos una carga detallada en absoluto. Pero, por supuesto, realmente no podemos hacer APIs separadas para el servidor y el cliente, porque cuando desarrollamos nuestras aplicaciones, nuestras aplicaciones son documentos vivos. Los componentes del cliente se convierten en componentes del servidor, se convierten en componentes del cliente, se agregan componentes, se eliminan componentes. Entonces, mantener la carga imperativa en sincronía con todo eso sería demasiado trabajo, demasiada sobrecarga. Entonces, cuando se trata de cargar traducciones, los espacios de nombres realmente ya no son la forma de hacerlo cuando se introducen componentes del servidor en la mezcla, porque se convierte en una cantidad prohibitiva de esfuerzo que debes poner para cargar lo que necesitas y solo lo que necesitas. Seguramente tiene que haber una mejor manera. Retrocedamos un paso y comencemos a pensar en lo que realmente estamos tratando de hacer cuando hacemos estas liberaciones de espacios de nombres. Lo que estamos tratando de expresar es que este componente depende de estos mensajes, este code depende de eso. Y en JavaScript, tenemos esta maravillosa herramienta llamada declaración de importación, que expresa esa relación muy, muy bien. Y tenemos herramientas que pueden analizar eso, enlazadores que pueden ajustar y todo lo que realmente pueden aprovechar al máximo.

Imaginemos que en lugar de espacios de nombres ordenados o archivos JSON, tuviéramos un archivo JavaScript gigante donde todos nuestros mensajes que existen en nuestra aplicación están presentes y se exportan por separado. Ahora no nos preocupemos de dónde obtuvimos ese archivo. Supongamos que lo tenemos. Puedes ver esto a la izquierda aquí, lo que podemos hacer en nuestros componentes, independientemente de si son componentes del cliente o componentes del servidor, es simplemente importar desde ese archivo y usar los mensajes que queremos. Y nuestras herramientas de compilación, o Redpack o TurboPack, serán lo suficientemente inteligentes como para ver, está bien, estamos usando exactamente este mensaje y solo son estos mensajes y los estamos usando en el cliente. Puede hacer esto por separado para el servidor y el cliente, aunque el code sea idéntico. Por lo tanto, podrá ver qué mensajes estamos utilizando y podrá eliminar todos los demás. Así que obtenemos el conjunto mínimo de mensajes que se utilizan en el cliente. Si estás desarrollando, es muy común que tu componente del cliente se convierta en un componente del servidor o viceversa, generalmente solo agregando o eliminando la parte de uso del cliente allí. Y la eliminación de árboles en nuestros enlazadores es lo suficientemente inteligente como para hacer esto correctamente. Entonces, si elimino el uso del cliente allí, todos los mensajes ya no se enviarían al cliente. Estamos enviando la menor cantidad de bytes posible. Esta es una carga detallada perfecta.

Ahora, por supuesto, probablemente no quieras escribir realmente un archivo de mensajes de este tipo tú mismo. Es bastante sencillo si solo estás usando cadenas, pero si tienes tus formatos de mensajes ICU con un montón de plurales, formatos de moneda y todo eso. Va a ser muy, muy tedioso de mantener. Y, por supuesto, tus traductores no podrán trabajar con eso. Entonces, querrás generar este archivo de alguna manera. Hay un montón de herramientas disponibles para hacer esto. Pero yo mismo, he estado trabajando en una. Se llama Paraglide.js. Hace exactamente lo que acabo de decir, solo toma archivos de traducción y te da un archivo de mensajes gigante, y luego puedes usar esas declaraciones de entrada para expresar todas las relaciones que necesitas. Y ya no necesitas preocuparte por hacer ninguna carga imperativa en absoluto. Esa es mi presentación. Por favor, deja de usar espacios de nombres para cargar cosas. Ya no son adecuados para el propósito. Y prueba una biblioteca como Paraglide.js. Gracias.