Construyendo aplicaciones JS con internacionalización (i18n) en mente

¡Hola, JS Nation! ¡Gracias por unirse a mí hoy! Estoy muy emocionado de compartir con ustedes algunas ideas sobre cómo construir aplicaciones JavaScript teniendo en cuenta la internacionalización. Mi nombre es Naomi Meier y trabajo en el equipo de ingeniería de globalización en Adobe, donde me dedico a la ingeniería de internacionalización para muchas aplicaciones de Adobe diferentes.

Entonces, aquí es donde puedes encontrarme en línea, en mi Twitter y mi sitio web. Y si hay algo en lo que te sientas apasionado, por favor avísame. Me encantaría continuar esta conversación en línea. Así que aquí está nuestra agenda para hoy. Voy a comenzar con un ejemplo de nombre y luego pasar a algunas definiciones de localización, internacionalización, globalización, solo para nivelar y asegurarnos de que todos estemos en la misma página. Y luego pasaré a mis cinco mejores consejos para evitar los errores más comunes que encontramos al internacionalizar JavaScript. Y luego terminaré con la culturalización. En general, el objetivo de esta presentación general es animarlos a todos a crear experiencias igualmente utilizables, relevantes y significativas para los usuarios de todo el mundo, y realmente amplificar las voces de nuestros usuarios globales. Así que me gustaría invitarlos y animarlos, ya saben, mis compañeros codificadores de JS, a salir y realmente poner el mundo en la World Wide Web. Así que hablemos de cómo podemos hacer eso.

Comencemos con un ejemplo de nombre. Entonces, esto es, ya saben, una cadena muy común que vemos a menudo en inglés, donde las personas se presentan con la sintaxis de 'Hola, mi nombre es Naomi Meyer'. Este es mi primer nombre o nombre de pila en azul, seguido de mi apellido, nombre de familia o apellido. Si tomamos esta cadena simple y la traducimos al japonés, hindi, hebreo, árabe, coreano y chino, podemos ver que la sintaxis de nombre de pila, apellido a veces se invierte. A veces es apellido, nombre de pila y, obviamente, a veces el texto se lee de izquierda a derecha. A veces el texto se lee de derecha a izquierda. Y esto es solo una representación visual de cómo podemos identificar el nombre de un usuario de manera diferente en diferentes ubicaciones. Y este es un problema de alto nivel que estamos tratando de resolver con internacionalización. Mi nombre es un nombre simple de inglés estadounidense. Aquí hay un ejemplo de algunos otros nombres de Brasil y portugués, Rusia e India. Nombres comunes y cómo no encajan fácilmente en este paradigma simple de nombre de pila, apellido. Y algunos de los desafíos a los que nos enfrentamos aquí. Así es como Google resuelve ese problema cuando creas una cuenta de Google, ingresas un nombre de pila y un apellido como campos de datos distintos. Entonces, los usuarios de regiones e idiomas que no siguen necesariamente ese paradigma tendrán problemas. Pero Twitter recientemente encontró una gran solución a este problema donde tienen simplemente un campo de nombre donde un usuario puede ingresar su nombre y su guión nativo y su sintaxis nativa de nombre de pila, apellido, apellido, nombre de pila. Y se almacenará como un campo distinto. Creo que esta es una solución realmente genial para el problema de la internacionalización del nombre de usuario. Ahora que nuestras mentes están pensando más profundamente en la internacionalización, pasemos a algunas definiciones.

Entonces, ¿de qué estamos hablando aquí? Cuando comenzamos en el nivel más granular, tenemos la traducción donde, ya sabes, hello se convierte en ola, konichiwa, bonjour. Luego, el siguiente nivel de granularidad sería la localización. Y eso es, ya sabes, en inglés escribimos localización con Z en Estados Unidos. Pero si vas al Reino Unido, localización se escribe con una S. Y ambos son inglés, pero son diferentes variaciones dialectales regionales. Así que ese es el nivel de localidad al que llegamos con la localización.

El siguiente nivel de granularidad es la internationalization. Y esto es más en el lado de la ingeniería, donde envolvemos la aplicación en herramientas para internationalization para que puedan ser enviadas en forms traducidos. Aquí es donde entramos en los tubos, donde si un software es una casa, alcanzaremos los tubos, los cambiaremos. Y crearemos un sistema que pueda ser fácilmente traducido. Luego, el siguiente nivel de granularidad es la globalización, y todos estos caen bajo el paraguas de la globalización o G11N. Y es importante tener en cuenta que estos son acrónimos numéricos. Entonces, para la globalización, tomamos el primer carácter G, seguido del número de caracteres y luego el último carácter N. Y cuanto más pienso en estas grandes ideas, la cultura está profundamente arraigada en nuestro pensamiento patterns y afecta cómo nuestros usuarios interactúan y se benefician de las experiencias digitales. Entonces, la internationalization o globalización realmente van más allá de la traducción. Y al reconocer las características culturales y celebrar las diferencias, estamos creando con innovation y accesibilidad y construyendo productos para todo el mundo de usuarios.

Entonces, si miramos estas dos visualizaciones, podemos ver que la mayoría de las personas en la Tierra no hablan inglés como primer idioma. Pero podemos ver que la mayoría del contenido digital está en inglés en este momento. Así que esta es realmente una oportunidad para nosotros de expandir el contenido digital en línea a diferentes idiomas para usuarios de todo el mundo que lo usen en su lengua materna. Así que hablemos de los cinco principales tips sobre cómo podemos hacer eso. Así que el primer consejo es utilizar Unicode en todas partes. Entonces, para empezar, ¿qué es Unicode? Estoy seguro de que todos estamos muy familiarizados con ver esta línea en nuestras etiquetas HTML donde decimos meta char set equals UTF 8 para la web. Entonces, ¿qué es UTF? UTF es el formato de transformación Unicode. Unicode, ¿verdad? Así es como se representa UTF en 8, 16 y 32 bits, para el carácter A y el carácter O, en japonés. Y UTF 8 es el más común en la web. UTF 16 se utiliza en Java y Windows, y 32 se utiliza en Linux y varios sistemas Unix. Así que UTF es realmente genial porque es reversible, y las conversiones entre todos están basadas algorítmicamente y son rápidas y evitan la pérdida de información en el viaje de ida y vuelta. Entonces sabemos que muchos lenguajes de programación utilizarán directamente una de estas codificaciones UTF. Pero como ingenieros de JavaScript, ¿qué UTF utiliza JavaScript? Esto es realmente importante cuando pensamos en la codificación. Y ya sea que estés en Reactor, Angular, View o Spelt, todos están codificados de la misma manera bajo el capó.

Entonces, si observamos la especificación ECMAScript, la versión estandarizada de JavaScript define cómo se deben interpretar los caracteres como UCS 2 o UTF 16. UCS 2 es un conjunto de caracteres universal de dos bytes en comparación con UTF 16, que es un formato de transformación Unicode de 16 bits. Estos son dos sistemas diferentes y contrastantes. Por lo tanto, esto crea muchos errores extraños e interesantes en JavaScript al tratar la codificación de caracteres. Debido a estos sistemas contrastantes, uno siempre tiene dos bytes y el otro utiliza pares de sustitución.

Hablemos de algunos de esos errores comunes que vemos. El primero es con los caracteres combinados. Los caracteres combinados son aquellos en los que tomamos un punto de código Unicode para la letra minúscula `a` en latín, y luego agregamos un punto de código de carácter combinado. Aquí tenemos un anillo combinado encima. Así es como se representa un carácter de nombre de gráfico atómico danés que tiene una `a` con un pequeño círculo encima, por lo que la `a` con un pequeño círculo encima son dos puntos de código separados que se combinan en uno solo. Entonces, si tomamos estos dos caracteres separados y los mostramos en la consola, podemos ver que se devuelve la `a` con un pequeño círculo encima. Genial, pero debido a que son dos caracteres separados, podemos ver algunos problemas.

Similar a esa `a` con un círculo encima, tenemos la `e` con la `e` acentuada en `café`, que vemos en español. Entonces, si definimos esa variable como `drink`, con C-A-F-E con el último punto de código combinado como el acento en `café`, y luego mostramos esa variable `drink` en la consola, podemos ver que se devuelve `café`. Pero luego, si verificamos la longitud de `drink`, la longitud es cinco. Y si intentamos dividir esa cadena en un array, podemos ver que el índice final del array es ese punto de código combinado. Como puedes imaginar, surgirán muchas confusiones al manipular cadenas con caracteres combinados, cuando olvidas que existen estas secuencias de código. Entonces, ¿cómo podemos manejar eso? Usando el método normalize que está incorporado en JavaScript. El método string.prototype.normalize devuelve la forma de normalización Unicode de la cadena. Lo cual es realmente útil, directamente desde JavaScript. Entonces, si tomamos esa misma variable `drink`, que es `café` con el punto de código combinado, y normalizamos esa cadena, ahora podemos ver que la longitud se devuelve como cuatro, y el índice final del array al dividirlo es la `e` con el acento encima. Entonces no obtenemos ese índice adicional con el punto de código combinado. Esto es realmente útil para evitar errores de localización al manipular cadenas. Pero también es muy importante desde la perspectiva humana. Recientemente vi este tweet que dice: encontrado en un sitio web del gobierno de EE. UU., esto es lo que es el racismo sistémico, es cuando las personas son excluidas. Entonces, esta persona Raquel Velez, su apellido está en español y tiene un acento sobre la `e`, pero no puede ingresar su apellido en el campo de apellido de un formulario del gobierno de EE. UU. debido al punto de código combinado en Unicode que está creando problemas de codificación aquí. Al solucionar problemas simples de cadenas y codificación, podemos ayudar a resolver estos problemas a nivel humano.

Entonces, pasemos al segundo consejo, envolver todas las cadenas en un objeto para la traducción. Desde un ejemplo de seudocódigo a un nivel muy alto aquí, podemos tomar una cadena `hello` codificada en duro de `hello world` y luego, esto es una cadena codificada en duro, esto es lo que no debemos hacer, pero lo que podemos hacer en su lugar es tomar esta cadena y envolverla en un objeto de internacionalización donde tenemos una lista de recursos para cada una de las diferentes ubicaciones. Entonces aquí podemos ver que el inglés tiene un objeto con la clave del mensaje de saludo que es igual al valor de la clave, el valor es `hello world`.

Y luego podemos mostrar esa variable del mensaje de saludo como la clave y devolver hola mundo como el valor. Así que aquí está este ejemplo simple en inglés y luego lo que podemos hacer es agregar locales adicionales en nuestros archivos de recursos. Así que aquí está este local en japonés, ya sabes, Konnichiwa. Y la mejor práctica es tomar cada uno de estos diferentes recursos como locales distintos y almacenarlos como archivos diferentes en tu lista de archivos. Y hay muchas formas diferentes de hacer eso. Hay muchas herramientas de código abierto realmente excelentes que están disponibles. Aquí hay una lista de algunas que recomiendo. IAT next, GlobalizedJS, PolyGotJS y Localize. Hay muchas más que son sistemas excelentes para básicamente envolver todas tus cadenas en un objeto para la traducción. Así que no voy a entrar en los detalles profundos de estas implementaciones individuales, sino que quiero centrarme en soluciones más generales que sean independientes de la herramienta y hablar sobre consejos de alto nivel que se pueden aplicar en todas estas diferentes herramientas.

Entonces, el siguiente consejo, consejo número tres, es probar en diferentes idiomas y diferentes conjuntos de caracteres. Una gran solución para testing en diferentes idiomas y diferentes conjuntos de caracteres es utilizar la prueba del montón de excremento. Esto es de Matheus Baynards y él dice que si incluyes un emoji de montón de excremento debido a la codificación Unicode subyacente en JavaScript, estos emojis probarán cómo manejas caracteres Unicode complejos o también puedes incluir esta larga cadena de emojis de montón de excremento para asegurarte de que la codificación funcione correctamente de principio a fin en tu aplicación de JavaScript. Y recomiendo encarecidamente testing tantos caracteres complejos como sea posible.

Entonces, el consejo número cuatro es envolver todos tus números especialmente fechas, horas y monedas en un objeto para la internacionalización. Una maravillosa solución que viene incluida con JavaScript es el objeto JSINTL. Esa es una API que tiene muchas cosas realmente geniales aquí que vienen con JavaScript de forma gratuita. Así que solo unos pocos ejemplos de lo que está disponible en el objeto INTL para fechas y horas. Aquí tenemos el formato de número donde podemos ingresar una localización y un número entero largo y luego mostrarlo correctamente según esa configuración de localización. Así que aquí podemos ver ese número entero largo en inglés con una coma cada tercer número, en alemán con el punto, en ruso con un espacio. Y luego en tamil e hindi, la coma se incluye en una ubicación diferente dentro de ese número entero largo porque tienen diferentes sistemas de ordenamiento de números, lo cual me parece bastante genial. Y luego también, la antigua pregunta, ¿qué día es hoy? Depende de dónde lo preguntes. A veces puede ser el 2 de enero, a veces puede ser el 1 de febrero. Aquí hay una divertida visualización de cómo cambian las fechas dependiendo de dónde las estés mostrando. Y aquí tienes un ejemplo de cómo usar el objeto JavaScript INTL con el formato de fecha y hora, donde podemos formatear un rango de fechas. Entonces, si ingresamos una fecha de inicio y una fecha de fin, así es como se verá en diferentes localizaciones. Y creo que es realmente emocionante ver todos esos símbolos específicos de localización. Además, Unicode tiene ISO para ayudarte a manejar fechas y eso es otro maravilloso proyecto de código abierto.

Entonces, mi consejo número cinco es crear diseños flexibles para acomodar el texto traducido. Obviamente, diferentes idiomas tienen diferentes longitudes de texto. El Sistema de Diseño Adobe Spectrum recomienda utilizar estas reglas. Entonces, dependiendo de la longitud de tus textos en inglés permite una expansión del texto del 300% al 30% y probar en estas diferentes longitudes más largas y más cortas de texto es realmente importante. Y luego también recuerda que cosas como la cursiva y la negrita y el espaciado entre líneas pueden cambiar mucho en diferentes idiomas y considerar la legibilidad del usuario en caracteres japoneses, chinos o coreanos complejos aquí. Así que esos son mis cinco principales tips a tener en cuenta, pero también hay muchas cosas que son realmente importantes en la internacionalización que simplemente no tengo tiempo para explicar hoy. Así que algunas cosas a tener en cuenta también son evitar la concatenación de cadenas porque el orden de las palabras cambiará en diferentes idiomas. Y también asegúrate de manejar la clasificación, el filtrado y la búsqueda en caracteres no ingleses. Y luego asegúrate de utilizar un manejo consistente de códigos de localización. Nuestra recomendación es utilizar BCP 47 para definir tus localizaciones y asegurarte de que donde se defina la localización sea consistente en toda la aplicación. Y luego recuerda que los teclados y los atajos de teclado pueden variar en diferentes regiones. Así que asegúrate de tenerlo en cuenta y recuerda si tienes una tecla de acceso rápido verificar las diferentes disposiciones regionales de los teclados.

Y luego, por supuesto, el cambio de izquierda a derecha afecta el diseño de toda tu interfaz de usuario para los usuarios que leen de izquierda a derecha. Y si estás apoyando a esos usuarios, asegúrate de tenerlo en cuenta.

En cada una de mis diapositivas, tengo enlaces a más documentación. Así que siéntete libre de entrar y leer eso y aprender más sobre cómo manejar todos estos casos complicados. Desafortunadamente, no tengo tiempo para hablar sobre todas las cosas increíbles que me encantaría hablar hoy.

Pero pasemos a las consideraciones culturales a tener en cuenta en el panorama general de la internacionalización. Entonces, ya sabes, es completamente... Si un usuario está buscando una imagen para representar una festividad, todas estas diferentes imágenes son válidas, sabes, festividades verdaderas y maravillosas en todo el mundo, y reconocer diferentes culturas es muy importante. También la comida, ya sabes, si un usuario está buscando comida deliciosa, creo que todos estaríamos de acuerdo en que tener una variedad, sabores picantes, dulces y salados, tener todas estas opciones diferentes es realmente genial e importante. Y al igual que tener una variedad de opciones de comida deliciosa, tener una variedad de idiomas es culturalmente útil e importante.

Este mapa representa, cada punto representa un idioma que está en riesgo actualmente. Por lo tanto, al habilitar diferentes idiomas y permitir que los usuarios de diferentes idiomas realmente puedan navegar por nuestras aplicaciones en sus lenguas maternas, estamos verdaderamente innovando y construyendo para el mundo completo de seres humanos en la Tierra. Así que por favor, únete a mí, evita hacer suposiciones, amplía tu mente y sal ahí y coloca al mundo en la World Wide Web. Muchas gracias. Adiós. Gracias. Adiós. Gracias. Adiós. Adiós. Gracias. Adiós. Gracias. Adiós. Adiós. Adiós. Adiós. Gracias. Adiós. Gracias.

Adiós. Gracias. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.

Gracias. Adiós. Adiós. Adiós. Adiós. Adiós.