¡Vamos a Remixear para Localizar Contenido!

Estoy muy emocionado de hablar sobre Remix e internacionalización. Bueno, sin perder más tiempo, aquí hay algunas cosas sobre mí. Mi nombre es Eryssa y soy ingeniero, así como embajador en Girl Code y Google Developer Expert en tecnologías web. Bueno, hay tres puntos clave de mi charla. En primer lugar, vamos a ver el impacto de la internacionalización, así como la lógica fundamental, y por último, vamos a ver cómo Remix e internacionalización trabajan juntos. Hay algunas notas que quiero que tengan en cuenta antes de ver mi charla. En primer lugar, todavía hay discusiones activas sobre Remix e internacionalización. Esto significa que ustedes podrían ser una de las personas que contribuyan a mejorar la experiencia de desarrollo. Así que, sí, siéntanse libres de echar un vistazo a las discusiones, o incluso unirse a ellas. Compartiré con ustedes las diapositivas más adelante, después de mi charla en Twitter, para que tengan acceso a todos los enlaces que, sí, pegué en estas diapositivas. Muy bien. Así que, vamos al grano. Estamos aquí para hablar sobre la internacionalización, y cómo funciona con Remix. Mientras preparaba mi charla, quería incluir tantas opiniones como fuera posible de los desarrolladores, no solo desde mi punto de vista. Así que, comencé a hacer esta pregunta en Twitter. ¿Les gusta implementar la lógica de internacionalización? Y este es el resultado que obtuve. Así que, en primer lugar, obtuve el resultado de 36 desarrolladores, y dicen que aproximadamente el 41.7% de los desarrolladores, dicen que no es su favorito. Es un proceso un poco molesto de hacer. Y basado en este hecho, también quería saber, okay, quiero saber más sobre los detalles, pero probablemente por lo que veo, esta rápida encuesta en Twitter, tal vez para nosotros los desarrolladores, no es un tema prioritario en comparación con el rendimiento y la accesibilidad. Pero por supuesto, quiero saber más. ¿Por qué? Así que pregunté. Si la internacionalización no es tu parte favorita, ¿por qué es así? Así que aquí está mi amiga, Maya, que me respondió. Gracias, y en primer lugar, ella dice que, bueno, no es como si ella implementara características de internacionalización a diario, significa que cuando necesita hacerlo, necesita volver a ver cómo funciona desde las bibliotecas de internacionalización o los frameworks que usa cada vez. Además, hay un pequeño problema entre el texto localizado y las claves de internacionalización, ya saben, durante las pruebas. Así que sabemos que, okay, probablemente la internacionalización no es el tema más popular, y no es algo divertido para los desarrolladores. Y basado en lo que pensamos, por supuesto, también necesitamos ver cómo es en el mundo y cómo es desde la perspectiva del usuario. Así que aquí están los pequeños números y efectos. Me gustaría comenzar desde números más grandes. En primer lugar,

Quiero que pienses en este número. ¿Qué crees que representa este número de 5.07 mil millones? En realidad, es la cantidad de usuarios en el mundo que utilizan Internet. Desglosando estos grandes miles de millones en porcentajes más pequeños, comenzando desde el 25.9 por ciento. ¿Qué opinas sobre este porcentaje? En realidad, es el porcentaje de contenido en inglés en Internet. El 25.9 es menos del 50 por ciento, lo que significa que si eres bueno en matemáticas, podrías calcular este número. El 74.1 sí, ese es el resto del porcentaje de los usuarios que acceden a contenido no en inglés en Internet, lo que nos lleva a esta palabra clave, China. Entonces, China tiene la mayor cantidad de usuarios de Internet en todo el mundo. No es sorprendente basado en este hecho. También podríamos pensar en esta palabra clave, Asia, sí, Asia necesita más de la mitad de los usuarios de Internet a nivel global. Es enorme, ¿verdad? Así que sí, ahora lo sabemos. Probablemente la localización de contenido no es el tema más candente para nosotros, los desarrolladores. Sin embargo, no podemos ignorar, sin importar qué, a más de la mitad de los usuarios en el mundo. Son números demasiado grandes para ignorar. Basándonos en lo que sabemos y sentimos, hablemos sobre la lógica fundamental de la internacionalización. En primer lugar, la internacionalización funciona de tres formas para determinar los idiomas y las regiones. El primer enfoque, el más avanzado aquí, es la ubicación a partir de la dirección IP, lo que significa que basado en la dirección IP, por ejemplo, donde me encuentro ahora mismo en Alemania, el contenido que veo en Internet detectará que estoy en Alemania, por lo que el contenido se mostrará, a veces, en alemán, si utilizan este enfoque. Si utilizan el segundo enfoque, significa utilizar el encabezado de idioma aceptado de la solicitud HTTP o los idiomas del navegador, significa que se fijarán en mis preferencias de idioma. Entonces, en el navegador, prefiero utilizar el inglés, eso es lo que configuro en mi configuración, y eso es lo que, ya sabes, se utilizará para devolverme el contenido localizado. Así que, a veces, incluso cuando estoy en Alemania, veo el contenido en inglés como preferí. Y la tercera opción es utilizar el identificador en la URL. Básicamente, se trata de traducir o localizar la URL para los usuarios. Esto significa que, por ejemplo, tendré los botones de selección de idioma en inglés, alemán y japonés en el navegador, y puedo hacer clic para seleccionar los idiomas que quiero ver. En esta charla, vamos a utilizar dos formas para ir híbridos porque quiero que nuestros usuarios sean más flexibles y tengan más control por sí mismos. Así que les dejaré la opción de cambiar los idiomas que prefieran en el navegador desde la interfaz de usuario, así como, en primer lugar, detectar su configuración de idioma preferido en el navegador. Así que vimos juntos cómo funciona o cuál es la lógica fundamental en la internacionalización. En cuanto a la URL del identificador, hay tres patrones para analizar. Así que vamos a desglosarlo. Así que, patrón uno. Esta es una forma de diferenciar, ya sabes, el contenido localizado por dominios. Básicamente, vas a crear un tipo de sitio web totalmente diferente en este caso. Pero los dominios son

diferente. Por lo tanto, no seguirá la misma política de origen. Esto significa que tus sitios web podrían ser considerados como una especie de copia. Desde la perspectiva de la security, es sospechoso.

Pasemos al patrón dos. El patrón dos utiliza los parámetros de la URL. Tal vez para los desarrolladores tenga sentido, pero no es amigable para los usuarios. Y también para todos, esta URL no se ve limpia, ¿verdad? Así que no queremos seguir este camino.

Pasando al patrón tres, que es la localización de subdirectorios. En este caso, vamos a agregar el slug localizado después de something.com para la barra diagonal. De esta manera, es bastante claro para los usuarios en qué idiomas están viendo el contenido, y también es más fácil para nosotros identificar qué idioma entregamos a los usuarios.

Muy bien, ahora hablemos de los frameworks y las bibliotecas. ¿Por qué de repente de la nada? Bueno, en realidad es un tema bastante relevante, porque algunos de los frameworks y las bibliotecas utilizan la internacionalización de los frameworks. Veamos cómo funciona en Remix. En el caso de Remix, en general hay dos enfoques para elegir. La primera opción sería usar el paquete code y Remixi18next, y el segundo enfoque sería utilizar un sistema de gestión de contenido.

Primero, veamos qué es Remixi18next. ¿Recuerdas que te dije antes que es un paquete npm, verdad? Y más precisamente, está hecho para que Remix utilice este framework de internacionalización llamado i18next, que fue creado por Sergio. Así que, gracias Sergio por crear un paquete npm tan increíble, porque ahora, gracias a eso, tenemos más opciones para elegir. Muy bien, veamos el ejemplo de este caso. En primer lugar, vamos a crear un par de archivos de configuración. Pero para empezar, vamos a crear los archivos traducidos. En este caso, voy a crear un idioma predeterminado y otro idioma. Así que establecí el inglés como idioma predeterminado. En el lado derecho, en la parte superior, creé el archivo llamado common.json. Te mostraré por qué ya sé que puedo dar un nombre al archivo common.json en este caso. Pero por ahora, centrémonos en cómo podemos aceptar el nombre de la propiedad y los valores clave, que en realidad son valores de cadena localizados. En primer lugar, he decidido llamar a esta propiedad nombre de saludo. Este valor lo usaré cuando traduzca desde el código fuente. En el lado derecho está el valor clave,

que es un valor de cadena localizado. Quiero decir hola en inglés para traducirlo al japonés. En este caso, he creado otro archivo traducido para, ya sabes, almacenar, ya sabes, este archivo traducido en japonés bajo el directorio de JA. Entonces, el valor será hola en japonés. Así que, después de crear estos archivos traducidos, vamos a crear el archivo de configuración de i18next.

Como dije antes, por alguna razón, ya sabía que podía dar el nombre de los archivos traducidos como common.js, ¿verdad? ¿Verdad? Así que aquí está la razón por la que. Si prestas atención a este NS predeterminado, por cierto, NS significa espacios de nombres, y le di el nombre como common. Por eso ya sabía que podía darle el nombre common.js. Así que hay un par de otras configuraciones, pero nada demasiado complicado, porque primero de todo, solo quiero enumerar los idiomas admitidos, inglés, japonés y, por supuesto, quiero tener un idioma de respaldo como idioma predeterminado. Basado en lo que creamos, los archivos traducidos y también la configuración del archivo de i18next.

Ahora es el momento de importar este archivo de configuración de i18next en el archivo i18next.server.js. Después de importarlo, por supuesto, quiero llamar a un par de valores. En primer lugar, la lista de idiomas admitidos y también la lista de idiomas de respaldo. Y basado en eso, recuerda esto, ya sabes, como el archivo de configuración que creamos, estas, ya sabes, como las listas de idiomas son los arrays dentro de los arrays y los valores dentro son cadenas. Así que puedo iterar estos valores desde la configuración del archivo que he creado. Y aquí, lo que estoy haciendo es establecer las rutas de los archivos de traducción. Muy bien. Ahora pasemos a crear los archivos de configuración del lado del cliente y del lado del servidor. Solo voy a mostrarte los detalles de los archivos de configuración del lado del cliente, porque puedes ver más detalles sobre los archivos de configuración del lado del servidor. Un par de líneas de código son bastante similares. Así que no quiero, ya sabes, repetir el contenido similar. Aquí está el archivo entry.client.jsx, que es el archivo de configuración del lado del cliente. Hay un par de líneas de código, pero quiero que prestes atención solo a las líneas de código resaltadas. Así que, en primer lugar, hay una API llamada i18next-provider que proviene de react-i18next. Ten en cuenta que de esta manera, vamos a instalar y usar un par de otros paquetes relacionados con i18next. Así que asegúrate de que esto provenga realmente de react-i18next. Después de haberte dicho que quería que prestes atención a esta API, aquí es donde puedes llamarla dentro del ámbito JSX. Así que vamos a envolver este componente del navegador de Remix que proviene del lado de Remix. Y vamos a ver la lógica, por qué necesitamos envolver este componente precisamente con esta API i18next-provider. Pero para darte un poco más de contexto, lo que estamos envolviendo es, bueno, este componente del navegador de Remix es o debería ser utilizado por react-hydrate para HTML. Así que hay otra pista de por qué insisto y resalto, ya sabes, estas líneas de código. En realidad, es muy importante ver el momento en que se va a hidratar y cargar los archivos de traducción.

Aquí están las respuestas para que las revisemos juntos. En primer lugar, veamos juntos por qué los archivos de traducción, ya sabes, deben cargarse antes de la hidratación. Bueno, probablemente empecemos a imaginarlo desde el punto de vista de si los archivos de traducción no se cargan antes de que ocurra la hidratación. Imagina que la hidratación, digamos, lo siento, no imagines, sino que cuando ocurre la hidratación, los usuarios ya pueden ver la interfaz de usuario con todos los estilos, ¿verdad? Pero la aplicación en sí aún no es interactiva. En este caso, los archivos de traducción aún no se han cargado y la hidratación ya ha ocurrido. Entonces, si quiero cambiar el idioma de inglés a japonés para decir hola, no puedo hacerlo porque en primer lugar estos valores de traducción aún no están listos. Basado en eso, si imaginamos que los archivos de traducción ya se han cargado antes de que ocurra la hidratación, ahora sabemos que este caso funcionaría porque la aplicación ya está de alguna manera interactiva. Entonces, cuando ocurre la hidratación, la interfaz de usuario está lista con los estilos y los archivos de traducción ya se han cargado. Entonces, si quiero cambiar de inglés a japonés para decir hola, ahora puedo hacerlo porque los archivos de traducción ya se han cargado.

Pasando a un poco más en profundidad, digamos, una pregunta basada en lo que vimos en el archivo de configuración del lado del cliente. Entonces, ¿por qué envolver, ya sabes, esta API deremix llamada remix browser con la API llamada proveedor i18next que proviene de I18next? Eché un vistazo a un poco más de detalles del archivomodules de nodo, y esto es lo que pude averiguar. Entonces, el proveedor i18n, en realidad incluye este ganchoreact de uso de memo. Este ganchoreact te permite almacenar en caché el resultado del cálculo entre las re-renderizaciones. Si lo digo de una manera más sencilla, básicamente, si los valores de esta configuración deinternacionalización y los espacios de nombres predeterminados, principalmente los archivos traducidos, son iguales, entonces no vamos a desencadenar la re-renderización porque eso te costaría mucho y no es eficiente. Queremos evitar que no sea eficiente, ¿verdad? Entonces, si los valores de estos, digamos cálculos son iguales, entonces los vamos a almacenar en caché y no desencadenar la re-renderización. Pero si los valores se actualizan, entonces vamos a desencadenar la re-renderización. Desde esta perspectiva, puedes ver que lainternacionalización es una especie de clave para mejorar elrendimiento o necesitas considerar también elrendimiento. Pero al usar todos estos paquetes, ya se tiene en cuenta, por lo que no es necesario implementar este tipo de características desde cero en tu lado. Así que, solo un poco de información sobre cómo configurar el archivo de configuración del lado del servidor en su totalidad, no quiero, en primer lugar, mencionar que la identificación de los idiomas preferidos de los usuarios y redirigirlos se puede hacer en el lado del servidor. Y si quieres echarle un vistazo, aquí está el enlace y el archivo readme para que lo revises. Muy bien, vamos a pasar a usar las configuraciones que hemos establecido hasta ahora en Action. Entonces, aquí vamos a echar un vistazo a este archivo llamado root.jsx en el directorio Android de la aplicación. Este es el archivo fundamental e importante, diría yo, en la aplicación deRemix. Así que aquí, quiero que prestes atención a tres APIs que provienen del lado deRemix. Comenzando por useLoaderData. Entonces, este useLoaderData obtendrá la configuración regional del función de carga y más arriba. Entonces, esta función de carga no es solo la función de ejecución que acabamos de definir. En cambio, en realidad es una APIbackend que proviene deRemix y ya está conectada a través del useLoaderData. Esto significa que estas APIs están vinculadas entre sí.

ya. Entonces, lo que necesitamos hacer al final es, en primer lugar, obtener la configuración regional, ¿verdad? Esto significa que necesitamos devolver la configuración regional. Para hacer eso, podemos, ya sabes, solicitar la respuesta para, ya sabes, que nos dé la configuración regional. Pero en lugar de, ya sabes, definir escribiendo, ya sabes, unas pocas líneas de código aquí para decir, por ejemplo, nuevas cabeceras de respuesta, etc., puedes llamar a otra API llamada JSON que proviene de Remix para completar este tipo de, digamos, proceso en una línea o en cada código. Muy bien. Veamos cómo funciona en el navegador . Así que veamos. Si cambio entre español e inglés, ahora puedes ver que los elementos de navegación del encabezado se están traduciendo. Y también el mensaje de saludo hola se ha traducido también. Y también los botones de abajo también. Entonces, para traducir, digamos, esta parte de hola, aquí tienes un pequeño ejemplo. En cualquier ruta de tu aplicación Remix, puedes importar esta traducción utilizada que proviene de React IAT next. Basado en lo que configuramos y creamos todos los fundamentos, todo lo que tenemos que hacer es envolver, ya sabes, la propiedad que proviene de los archivos traducidos. Recuerda que creamos dos archivos traducidos, ¿verdad? Y en la propiedad, dije que el cuerpo es saludo, así que eso es lo que estoy envolviendo. Así que aquí está el resultado que puedes ver. Y antes de pasar a la siguiente diapositiva, tengo una pequeña confesión para ti. Así que, necesitas, necesitas o quiero que prestes atención a esto aquí en la ruta de la URL. Ves una pequeña barra inclinada, que incluye los parámetros de la URL, ¿verdad? Así que aquí hay tres confesiones de mi parte. Seamos honestos. Utilizo los parámetros de la URL. Sí, y eso no es algo que quisiera hacer. De hecho, al principio de esta charla, te dije que no los evitaríamos. Y en segundo lugar, ¿los desarrolladores necesitamos mantener los archivos de traducción? Si pensamos en, digamos, el proceso o las configuraciones que hemos creado, ahora recordamos que hay dos archivos de traducción, ¿verdad?, en inglés y japonés. No queremos mantener estos archivos de traducción en el código fuente, ¿verdad? También la tercera confesión. ¿Hemos traducido estos segmentos de URL? No, no creo. Aún no he traducido estos segmentos. En su lugar, utilicé los parámetros de la URL. Y aquí hay otro amigo mío en Twitter, Bart, gracias de nuevo por tus comentarios. Él también consideró lo mismo. Así que, si quiere dividir los archivos de traducción por ruta, es posible, pero es un poco engorroso y, por supuesto, no es ideal encargarse de todos estos archivos traducidos en el código fuente, ¿verdad?

No queremos hacer eso. Además, quiere saber cómo localizar las URLs. Permítanme ser claro sobre lo que queremos lograr en el resto de mi charla. Queremos lograr una URL realmente localizada. Y también, no queremos tener archivos de traducción en nuestro código.

Entonces, aquí hay otro ejemplo, ya saben, basado en lo que vimos, Remix en general, puede tener dos enfoques para implementar la internacionalización. En primer lugar, echamos un vistazo juntos a usar este paquete NPM llamado Remix I18next y en segundo lugar, vamos a echar un vistazo al ejemplo de sistema de gestión de contenido. Así que pueden elegir cualquier tipo de sistema de gestión de contenido o CMS sin cabeza que esté disponible. En esta charla, elegí Storyblock porque es el CMS más cómodo y familiar para mí. Lo uso más. Y también, ofrece la mayor cantidad de estructuras para configurar cómo quieres localizar el contenido en el lado del CMS. Pero no voy a hablar sobre cómo puedes implementar entre Storyblock y Remix. Esto se puede explicar en este tutorial, digamos, publicación de blog para que puedas echarle un vistazo fácilmente después de mi charla. Muy bien. Dependiendo de los CMS sin cabeza o los CMS de tu elección, te dará de una a cuatro formas de estructurar para almacenar contenido localizado. Y como parte de ello, también te dará algunas posibilidades, no solo a ti, sino también a tus traductores y editores de contenido, para estructurar cómo quieren anidar estas rutas dinámicas. Desearía tener más tiempo para explicar y mostrarte estos cuatro enfoques, pero por cuestiones de tiempo, te mostraré esta traducción a nivel de carpeta.

Este enfoque es bastante sencillo porque, como puedes ver, todo el contenido localizado se almacena en carpetas dedicadas. Entonces, no hay forma de que los traductores mezclen páginas localizadas y el contenido. En primer lugar, antes de profundizar en cómo funciona a nivel de código fuente, te mostraré cómo funciona en el navegador.

Entonces, aquí estoy en la página de vista general del blog por defecto, que está en inglés, y por supuesto, si voy a ver el viaje a Salt Lake City, todas estas publicaciones de blog en inglés para páginas relevantes se almacenan en la carpeta. Digamos que la URL no debería incluir ningún fragmento porque este es el idioma por defecto, ¿verdad? Pero si voy a esta misma página exactamente, viajando a Salt Lake City en japonés, debería incluir JA, que significa el fragmento japonés, y también los contenidos se traducen en el lado derecho. Puedes ver que tus traductores pueden trabajar para almacenar los valores traducidos del contenido, y si vuelvo a la página anterior, que es la página de vista general del blog, también incluye JA en la URL, y si vuelvo a la página de inicio por defecto, que está en la raíz más alta, no debería incluir ningún fragmento de idioma, digamos, incluso EN. Y por supuesto, los contenidos vuelven a estar en inglés.

De esta manera, puedes ver que ya no tienes que lidiar con archivos traducidos en tu código fuente. En cambio, los traductores, que deberían ser los responsables de comenzar a traducir el contenido y gestionarlo donde debe almacenarse, pueden tener toda la flexibilidad. Y aquí está la pequeña lógica de cómo puedes crear este tipo de lógica de ruta dinámica. Entonces, en Remix, hay un par de formas de renderizar este tipo de rutas dinámicas. Pero elegí esta ruta plana, porque al usarla, permitirás que quien quiera crear las páginas e incluso crear rutas dinámicas anidadas desde el sistema de gestión de contenido, lo haga sin editar ningún código fuente. Una vez que implementes esta función mediante el uso de estas rutas planas, entonces las rutas dinámicas, incluso incluyendo la estructura anidada, se pueden hacer desde el lado del CMS. Así que aquí está la pequeña especie de

ejemplo. Ya conoces el uso del cargador data y JSON, ¿verdad? Así que voy a prestar más atención a estas líneas de código resaltadas en verde. Remix ya te proporciona un parámetro muy útil llamado params. Y si, digamos, haces un registro, si registras este parámetro con los corchetes cuadrados y el valor de cadena del asterisco, como puedes ver en el código fuente, cuando vas hacia adelante y hacia atrás entre diferentes páginas, te mostrará, ya sabes, la ruta completa, la ruta dinámica completa de las páginas que estás viendo. Así que estamos utilizando esta lógica para renderizar todas estas, ya sabes, rutas dinámicas, incluyendo las rutas anidadas. Así que aquí tienes un pequeño resumen de lo que vimos juntos en mi charla. Sabemos que más de la mitad de los usuarios en este mundo acceden a contenido localizado. Así que no podemos simplemente ignorar, ya sabes, a más de la mitad de los usuarios en este mundo. Correcto. También echamos un vistazo juntos a múltiples formas de hacer internationalization. Espero que te haya sido útil para elegir la mejor forma para tus casos, así como sabemos que, ya sabes, implementar la internationalization importa mucho para pensar en un mejor performance, también en la interfaz de usuario y la experiencia de usuario. Así que considera el performance y la interfaz de usuario, la experiencia de usuario, junto con la internationalization.

Hay una pequeña solicitud de mi parte al final. Así que por favor envíame el feedback, ya sabes, en Twitter. Realmente me encantaría mejorar mis charlas en general, cualquier feedback me ayudaría a mejorar. Puedes mencionar mi nombre, mencionar mi nombre de usuario en Twitter y tuitear sobre el feedback. Muy bien, eso sería todo de mi parte. Muchas gracias por ver mi charla. Y espero, uh, sí, que te haya gustado. Oh, hola Arisa. Y lo primero que queremos hacer, porque sé que hiciste la pregunta a todos nuestros espectadores, y querías saber en general, ¿cómo describirías tu experiencia de internacionalización hasta ahora? El 47% dijo regular, el 33% dijo que les gusta, y el 20% dijo que no les gusta en absoluto. Y creo que eso es aplicable a algunos de los desafíos a los que te puedes enfrentar al hacerlo. Y me gusta cómo las cosas están cambiando en tiempo real, así que es genial verlo. Así que para la mayoría de las personas, es regular. Y creo que es algo que es difícil de hacer, especialmente si alguien nunca lo ha hecho antes. Y creo que tu charla fue realmente útil para mostrarnos algunas de las formas de mejorar nuestra experiencia de desarrollo al buscar traducir contenido. Y sé que hay muchas personas diferentes en la audiencia que pueden tener preguntas. Pero en general, digamos que alguien es un principiante, y sé que has hablado un poco en tu charla, pero ¿por qué es importante la localización en tu opinión? Diría que la importancia de la localización es algo que puedes imaginar cuando lees la documentación de cualquier tipo de, digamos, tecnologías que quieras dominar. Imagina que tu primer idioma no es el inglés. Y eso significa que, digamos, si quieres entender realmente a algunos de los desarrolladores. Porque sé que soy de Japón, y sé cómo es el mundo tecnológico japonés

funcionaría. Y prefieren leer en contenido localizado para comprender mejor. Pero no siempre se traduce de inmediato. Dependiendo del número de desarrolladores que puedan ayudar. Y también, diría que la velocidad con la que también pueden contribuir al contenido. Entonces, esta especie de experiencia que obtienes es exactamente lo que tus usuarios obtendrían. Así que diría que la importancia de la internationalization es algo difícil de imaginar para ti cómo será para tus usuarios. El ejemplo que te di sería uno de los ejemplos que es posible que ya hayas experimentado.

Sí, no, eso es genial. Y la razón por la que quería preguntar eso primero es porque a veces es trabajo adicional para los desarrolladores agregar localización a todas las aplicaciones. Pero para los usuarios es simplemente un gran beneficio. Entonces, cualquiera que sea la experiencia, así que te guste o no, creo que al final del día, realmente ayuda a tus usuarios a navegar por tu sitio web y tener acceso al contenido basado en su ubicación y el idioma con el que se sienten más cómodos. Dicho esto, quiero hacerte una pregunta. En realidad, algo que le preguntamos a todos nuestros ponentes es, ¿cuál es tu característica favorita de Remix? Diría, o al principio iba a decir tal vez el cargador y la acción, pero cambié de opinión en el último minuto porque conocí a la otra conferencia en persona en Londres y un buen amigo mío dio una charla sobre la interfaz de usuario optimista y Remix. Y lo he estado usando durante bastante tiempo. No es que sea un experto en ello, pero realmente disfruto usando la interfaz de usuario optimista porque ya puedes dar en el lado de la interfaz de usuario información suficiente, mientras que los datos están tardando en procesarse y luego actualizar los datos en el lado de la capa de datos. Pero quiero decir, si ya tienes suficientes fuentes para mostrar a los usuarios, no necesitan ver los indicadores de carga todo el tiempo. Y sé cómo las personas o los usuarios realmente odian ver los indicadores de carga. A veces, he visto casos realmente extremos, como mis amigos, cada vez que ven un indicador de carga en un segundo, se van inmediatamente. ¡Dios mío! Sí, hay personas extremas por ahí, pero quiero decir, están en todas partes. Sí. Es increíble cómo Remix resuelve ese problema. Y volviendo a la charla que diste, sé que tenías algunos ejemplos diferentes, ¿cómo funcionan el resto de los enfoques de traducción? A partir de una de tus diapositivas, había una diapositiva que mostraba cuatro enfoques para crear una estructura de localización en un CMS, pero solo muestra un enfoque llamado traducciones a nivel de carpeta.

Sí. Eso es algo que también quería explicar en la charla, pero voy a aprovechar la oportunidad esta vez. Entonces, el resto de los cuatro enfoques sería tal vez comenzar desde un enfoque llamado traducción a nivel de campo. De esta manera, en lugar de crear las carpetas para almacenar todas las páginas de contenido localizado dentro de ellas, no necesitas crear las carpetas si no quieres. Y en su lugar, lo que puedes hacer para traducir o localizar el contenido es que estás

vas a decidir los tipos de campo. Significa como el titular dentro de la página principal o tipos de campos específicos y precisos. Tal vez como entradas o algo así para decidir si traducir. Así que hay casillas de verificación que puedes marcar para que sea traducible o no. De esta manera, puedes decidir qué componentes de los tipos de campo deben ser traducidos y localizados y qué tipo de componentes en el tipo de campo deben mantenerse en el idioma predeterminado. Si quieres utilizar este enfoque, entonces la traducción a nivel de campo es para ti. Y los otros dos enfoques se combinarían con este enfoque de traducción a nivel de campo que acabo de explicar. Y también se combinarían con la traducción a nivel de carpeta que presenté en mi charla. Así que habrá tres en total. Y el último enfoque sería, bueno, desde el sistema de gestión de contenido y precisamente desde el sistema de gestión de contenido sin cabeza, tenemos la terminología llamada espacios. Así que eso es algo que puedes imaginar como el repositorio o como, digamos, por ejemplo, la web en este caso. Puedes dedicar un espacio completo para un entorno para el idioma predeterminado primero, y luego otro espacio completo para otro contenido localizado, digamos, por ahí. Así que eso es algo que siempre explico, siempre explico como traducción a nivel de espacio. Así que habrá cuatro en total, traducción a nivel de campo, traducción a nivel de carpeta, una mezcla de ambos, y luego traducción a nivel de espacio.

Genial. Genial. Y solo una pregunta rápida aquí. ¿Crees que es mejor usar claves para identificar mensajes traducidos, o un mensaje completo, por ejemplo, saludos versus algo como hola mundo? Esa es una pregunta muy buena. Diría que para evitar la complejidad, dependiendo de qué claves localizadas, digamos, quieres tener, diría mantenlo lo más corto posible, porque podrías encontrar algunas incompatibilidades en la fase de testing, o un par de valores de clave que no coinciden en la fase de testing. Y eso es lo que realmente escuché de una de mis buenas amigas. Ella publicó en Twitter y respondió a mi pregunta al respecto.

Ok, eso tiene mucho sentido. Y se nos acabó el tiempo. Tenía muchas más preguntas, pero Arisa, muchas gracias por estar aquí. Gracias por esa increíble charla, y volvamos a Brittany. Gracias.