Internacionalización y localización para sitios estáticos

La internacionalización y la localización son más que solo escribir su contenido en varios idiomas. Necesita una estrategia para determinar qué localización enviar y el código para hacerlo. Debe poder admitir no solo diferentes idiomas, sino también diferentes regiones con el mismo idioma. Su interfaz de usuario debe responder, no solo al tamaño de la pantalla, sino también a los diferentes idiomas y modos de escritura. Su contenido debe estar estructurado, hasta la microcopia en su interfaz de usuario y el formato de sus fechas, para que sea adaptable a cualquier idioma que le presente. Hacer todo esto con un generador de sitios estáticos, como Eleventy, puede hacerlo aún más difícil, porque es posible que no tenga una base de datos, pero sí un servidor. Sin embargo, todo se puede hacer, pero requiere planificación.

Cuando construimos chromeOS.dev, sabíamos que necesitábamos ponerlo a disposición de una audiencia global. Asegurarse de que nuestra base de código pueda admitir varias configuraciones regionales (idioma, región o una combinación de las dos) sin necesidad de codificar cada una de ellas de manera personalizada, al mismo tiempo que permite que la traducción se realice con el menor conocimiento posible de ese sistema, sería fundamental para hacer esto pasa. Nuestros creadores de contenido necesitaban poder concentrarse en crear contenido, y nuestros traductores en traducir contenido, con el menor trabajo posible para llevar su trabajo al sitio e implementarlo. Acertar con este conjunto de necesidades, a veces en conflicto, es el corazón de lo que se necesita para internacionalizar las bases de código y localizar los sitios.

La internacionalización (i18n) y la localización (l10n) son dos caras de la misma moneda. La internacionalización tiene que ver con cómo, en nuestro caso, el software se diseña para que pueda adaptarse a múltiples idiomas y regiones sin necesidad de cambios de ingeniería. La localización, por otro lado, se trata realmente de adaptar el software para esos idiomas y regiones. La internacionalización puede ocurrir en toda la pila del sitio web; desde HTML, CSS y JS hasta consideraciones de diseño y creación de sistemas. La localización ocurre principalmente en la creación de contenido (tanto copia de formato largo como microcopia) y administración.

Nota : Para los curiosos, i18n y l10n son tipos de abreviaturas conocidas como numerónimos. A11y, por accesibilidad, es otro numerónimo común en el desarrollo web.

Internacionalización (i18n)

Al determinar la internacionalización, generalmente hay tres elementos que debe considerar: cómo determinar qué idioma y/o región quiere el usuario, cómo asegurarse de que obtenga contenido en su localización preferida y cómo adaptar su sitio para ajustarse a esas diferencias. Si bien las especificaciones de implementación pueden cambiar para los sitios dinámicos (que representan una página cuando un usuario lo solicita) y los sitios estáticos (donde las páginas se crean antes de implementarse), los conceptos básicos deben permanecer igual.

Determinación del idioma y la región del usuario

Lo primero que debe tener en cuenta al determinar la internacionalización es determinar cómo desea que los usuarios accedan al contenido localizado. Esta decisión se convertirá en la base de cómo configurar otros sistemas, por lo que es importante decidir esto temprano y asegurarse de que las compensaciones funcionen bien para sus usuarios.

Por lo general, existen tres formas de alto nivel para determinar qué localización ofrecer a los usuarios:

1. Ubicación desde la dirección IP;
2. Accept-Language header o navigator.languages ​​;
3. Identificador en URL.

Muchos sistemas terminan combinando uno, dos o los tres, al decidir qué localización servir. Sin embargo, mientras investigamos, encontramos problemas con el uso de direcciones IP y encabezados Accept-Language aceptado que pensamos que eran lo suficientemente importantes como para eliminarlos de nuestra consideración:

• El idioma preferido de un usuario a menudo no se correlaciona con su ubicación física, que proporciona la dirección IP. El hecho de que alguien se encuentre físicamente en Estados Unidos, por ejemplo, no significa que prefiera el contenido en inglés.
• El análisis de ubicación de las direcciones IP es difícil, generalmente poco confiable y puede evitar que los motores de búsqueda rastreen el sitio.
• Los encabezados Accept-Language a menudo nunca se establecen explícitamente y solo brindan información sobre el idioma, no sobre la región. Debido a sus limitaciones, esto puede ser útil para establecer una conjetura inicial sobre el idioma, pero no es necesariamente confiable.

Por estas razones, decidimos que sería mejor para nosotros no intentar inferir el idioma o la región antes de que un usuario llegue a nuestro sitio, sino tener indicadores sólidos en nuestras URL. Tener indicadores sólidos también nos permite suponer que obtienen el sitio en el idioma que desean solo a partir de su URL de acceso, proporciona una manera fácil de compartir contenido localizado directamente sin preocuparse por la redirección y proporciona una forma clara de dejar que los usuarios cambian su idioma preferido.

Hay tres patrones comunes para construir identificadores en URL:

1. Proporcione diferentes dominios (generalmente TLD o subdominios para diferentes regiones e idiomas (por ejemplo, example.com y example.de , en.example.org y de.example.org );
2. Tener subdirectorios localizados para el contenido (p. ej., example.com/en y example.com/de );
3. Sirva contenido localizado basado en parámetros de URL (p. ej., example.com?loc=en y example.com?loc=de ).

Si bien se usan comúnmente, los parámetros de URL generalmente no se recomiendan porque es difícil para los usuarios reconocer la localización (junto con una serie de problemas de análisis y administración). También decidimos que diferentes dominios no eran una buena solución para nosotros; nuestro sitio es una aplicación web progresiva y cada dominio, incluidos los TLD y los subdominios, se considera un origen diferente, lo que requiere un PWA independiente para cada localización.

Decidimos usar subdirectorios, lo que nos brindó la ventaja de poder localizar solo el idioma ( example.com/en ) o el idioma y la región ( example.com/en-US y example.com/en-GB ) según sea necesario mientras manteniendo una única PWA. También decidimos que cada localización de nuestro sitio viviría en un subdirectorio para que un idioma no se eleve por encima de otro, y que todas las URL, excepto el subdirectorio, serían idénticas en todas las localizaciones según el idioma de creación, lo que permitiría a los usuarios cambiar fácilmente localizaciones sin necesidad de traducir las URL.

Servicio de contenido localizado

Una vez que se ha determinado una estrategia para determinar el idioma y la región de un usuario, necesita una forma de brindarles el contenido correcto de manera confiable. Como mínimo, esto requerirá algún tipo de información almacenada, ya sea en una cookie, algún almacenamiento local o parte de la lógica personalizada de su aplicación. Ser capaz de mantener las preferencias de localización de un usuario es una parte importante de la experiencia del usuario de i18n; Si un usuario ha identificado que quiere contenido en alemán y llega al contenido en inglés, debería poder identificar su idioma preferido y redirigirlo de manera adecuada. Esto se puede hacer en el servidor, pero la solución que elegimos para chromeOS.dev es independiente del alojamiento y la configuración del servidor: usamos trabajadores de servicio. El viaje del usuario es el siguiente:

• Un usuario llega a nuestro sitio por primera vez. Nuestro trabajador de servicio no está instalado.
• Independientemente de la localización en la que aterricen, establecemos como su idioma preferido en IndexedDB. Para esto, asumimos que están aterrizando allí a través de algún medio, ya sea social, referencia o búsqueda, que los ha dirigido en función de otros contextos de localización que no tenemos. Si un usuario llega sin un conjunto de localización, lo configuramos en inglés, ya que ese es el idioma principal de nuestro sitio. También tenemos un conmutador de idioma en nuestro pie de página para permitir que un usuario cambie su idioma. En este punto, nuestro trabajador de servicio debe estar instalado.
• Una vez que se instala Service Worker, interceptamos todas las solicitudes de URL para la navegación del sitio. Debido a que nuestras localizaciones se basan en subdirectorios, podemos identificar fácilmente qué localización se solicita. Una vez identificada, verificamos si la página solicitada está en un subdirectorio localizado, verificamos si el subdirectorio localizado está en una lista de localizaciones admitidas y verificamos si el subdirectorio localizado coincide con sus preferencias almacenadas en IndexedDB. Si no está en un subdirectorio localizado o si el subdirectorio localizado coincide con sus preferencias, mostramos la página; de lo contrario, hacemos una redirección 302 de nuestro trabajador de servicio para la localización correcta.

Incluimos nuestra solución en el complemento de Workbox, Redirección de internacionalización de trabajadores de servicios. El complemento, junto con su submódulo de preferencias, se puede combinar para establecer y obtener la preferencia de idioma de un usuario y administrar la redirección cuando se combina con el método registerRoute de Workbox y el filtrado de solicitudes en request.mode === 'navigate' .

Un ejemplo completo y mínimo se ve así:

Codigo del cliente

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

Código de trabajador de servicio

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

Con la combinación del lado del cliente y el código del trabajador del servicio, la localización preferida de los usuarios se establecerá automáticamente cuando accedan al sitio por primera vez y, si navegan a una URL que no está en sus localizaciones preferidas, serán redirigido

Adaptación de la interfaz de usuario del sitio

Se necesita mucho para adaptar correctamente las interfaces de usuario, por lo que, si bien no se cubrirá todo aquí, hay un puñado de cosas más sutiles que pueden y deben administrarse mediante programación.

Cotizaciones en bloque

Un patrón de diseño común es tener comillas en bloque entre comillas, pero ¿sabía que lo que se usa para esas comillas varía según la localización? En lugar de codificar, use open-quote close-quote para asegurarse de que se usen las comillas correctas para el idioma correcto.

Formato de fecha y número

Tanto las fechas como los números tienen un método, .toLocaleString , para permitir el formato en función de una localización (idioma y/o región). Los navegadores que los admiten se envían con todas las localizaciones disponibles, lo que hace que sea fácilmente utilizable allí, pero Node.js no. Afortunadamente, el módulo full-icu para Node le permite usar todos los datos de localización disponibles. Para hacerlo, después de instalar el módulo, ejecute su código con la variable de entorno NODE_ICU_DATA establecida en la ruta al módulo, por ejemplo, NODE_ICU_DATA=node_modules/full-icu .

Metainformación HTML

Hay tres áreas en su etiqueta HTML y encabezados que deben actualizarse con cada localización:

• El idioma de la página,
• dirección de escritura,
• Idiomas alternativos en los que está disponible la página.

El primero en ir al elemento html con las propiedades dir y lang respectivamente, por ejemplo, <html lang="en" dir-"ltr"> para inglés estadounidense. La configuración adecuada garantizará que el contenido fluya en la dirección correcta y puede permitir que los navegadores comprendan en qué idioma se encuentra la página, lo que permite funciones adicionales como la traducción del contenido. También debe incluir enlaces rel="alternate" para que los motores de búsqueda sepan que una página se ha traducido por completo, por lo que incluir <link href="/es" rel="alternate" hreflang="es"> en nuestra página de destino en inglés informe a los motores de búsqueda que esto tiene una traducción que debería estar buscando.

Diseño intrínseco

La localización del contenido puede presentar desafíos de diseño, ya que las diferentes traducciones ocuparán una cantidad variable de espacio en la página. Algunos idiomas, como el alemán, tienen palabras más largas que requieren más espacio horizontal o un ajuste de texto más tolerante. Otros idiomas, como el árabe, tienen tipos de letra más altos que requieren más espacio vertical. Afortunadamente, hay una serie de herramientas CSS para hacer que el espaciado y el diseño respondan no solo al tamaño de la ventana gráfica, sino también al contenido, lo que significa que se adaptan mejor a varios idiomas.

Hay una serie de unidades de CSS diseñadas específicamente para trabajar con contenido. Hay unidades em y rem que representan el tamaño de fuente calculado y el tamaño de fuente raíz, respectivamente. El intercambio de valores de px de tamaño fijo para estas unidades puede contribuir en gran medida a que un sitio responda mejor a su contenido. Luego está la unidad ch , que representa el tamaño en línea del glifo 0 (cero) en una fuente. Esto le permite vincular cosas como width , por ejemplo, directamente al contenido que contiene.

Luego, estas unidades se pueden combinar con potentes herramientas CSS existentes para el diseño, específicamente flexbox y grid, para obtener componentes que se adapten a su tamaño, y los diseños se adapten a su contenido. Mejorar aquellos con propiedades lógicas para bordes, márgenes y relleno en lugar de propiedades físicas físicas hace que esos diseños y componentes también se adapten automáticamente al modo de escritura. El poder del diseño web intrínseco (acuñado por Jen Simmons), las unidades conscientes del contenido y las propiedades lógicas permiten diseñar y construir interfaces para que puedan adaptarse a cualquier idioma, no solo a cualquier tamaño de pantalla.

Localización (l10n)

La forma más obvia que toma la localización es traducir contenido de un idioma a otro. En formas más sutiles, las traducciones no solo ocurren por idioma, sino también por región en la que se habla, por ejemplo, inglés hablado en Estados Unidos versus inglés hablado en el Reino Unido, Sudáfrica o Australia. Para tener éxito aquí, comprender qué traducir y cómo estructurar su contenido para la traducción es fundamental para el éxito.

Estrategia de contenido

Hay algunas partes de un proyecto de software que es importante localizar y otras que no. Los nombres de clases de CSS, las variables de JavaScript y otros lugares en su base de código que son estructurales, pero que no están orientados al usuario, probablemente no necesiten ser localizados. Averiguar qué debe localizarse y cómo estructurarlo se reduce a la estrategia de contenido.

La estrategia de contenido tiene muchas definiciones, pero aquí se refiere a la estructura del contenido, microcopia (las palabras y frases utilizadas a lo largo de un proyecto que no están vinculadas a un contenido específico) y las conexiones de las mismas. Para obtener información más detallada sobre la estrategia de contenido, recomendaría Content Strategy for Mobile de Karen McGrane y Designing Connected Content de Carrie Hane y Mike Atherton.

Para chromeOS.dev, terminamos codificando modelos de contenido que describen la estructura de nuestro contenido. Los modelos de contenido no son solo para contenido similar a un artículo de formato largo; debe existir un modelo de contenido para cualquier entidad que un usuario pueda desear específicamente de usted, como un autor, un documento o incluso activos de medios reutilizables. Los buenos modelos de contenido incluyen piezas o fragmentos direccionables individualmente de una pieza conceptual más grande, al tiempo que excluyen fragmentos que están relacionados tangencialmente o a los que se puede hacer referencia desde otro modelo de contenido. Por ejemplo, un modelo de contenido para una publicación de blog puede incluir un título, una serie de etiquetas, una referencia a un autor, la fecha de publicación y el cuerpo de la publicación, pero no debe incluir la cadena para las migas de pan o el el nombre del autor y la imagen, que debe ser su propio modelo de contenido. Los modelos de contenido no cambian de una localización a otra; son la estructura del sitio. Una instancia de un modelo de contenido está vinculada a una localización y esas instancias se pueden localizar.

Sin embargo, los modelos de contenido solo cubren una parte de lo que debe localizarse. El resto, sus botones "Leer más", su título de "Menú", su texto de exención de responsabilidad, eso es todo microcopia. La microcopia también necesita estructura. Si bien los modelos de contenido pueden parecer naturales para crear, especialmente para sitios basados ​​en plantillas, los modelos de microcopia tienden a ser menos obvios y, a menudo, se pasan por alto accidentalmente al escribir lo que se necesita directamente en una plantilla.

Al crear contenido y modelos de microcopia y aplicarlos (a través de un sistema de administración de contenido, linting o revisión), puede asegurarse de que la localización pueda centrarse en la localización.

Localice valores, no claves

Los modelos de contenido y microcopia suelen generar estructuras similares a los objetos en una base de código; ya sean entradas de base de datos, objeto JSON, YAML o Front Matter. ¡No localice las claves de objeto! Si tiene su microcopia de texto de búsqueda ubicada en un objeto de microcopy en microcopy.search.text , no la coloque en un objeto de microcopie en microcopie.chercher.texte . Las claves en los módulos se deben tratar como identificadores independientes de la localización para que se puedan usar de manera confiable en plantillas reutilizables y se pueda confiar en ellas en una base de código. Esto también significa que las claves de objeto no deben mostrarse a los usuarios finales como contenido o microcopia.

Configuración del sitio estático

Para chromeOS.dev, usamos Eleventy (11ty) con Nunjucks como nuestro generador de sitios estáticos, pero estas recomendaciones para configurar un generador de sitios estáticos deberían aplicarse a la mayoría de los generadores de sitios estáticos. Cuando algo sea específico de 11ty, se mencionará.

Estructura de carpetas

Los generadores de sitios estáticos que compilan en función de la estructura de carpetas son particularmente buenos para admitir el método de subdirectorio i18n. 11ty también admite una cascada de datos con datos globales y un medio para generar páginas a partir de datos a través de la paginación, por lo que la combinación de estos tres conceptos produce una estructura de carpetas básica similar a la siguiente:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

En un nivel superior, hay un directorio para contener las páginas de un sitio, aquí llamado pages . Anidado en el interior, hay una carpeta _data que contiene archivos de datos globales. Esta carpeta es importante cuando se habla de ayudantes a continuación. Luego, hay una carpeta _generated . Tenemos una serie de páginas que, en lugar de tener su propio contenido, se generan a partir de contenido existente, pequeñas cantidades de microcopias o una combinación de ambos. Piense en una página de inicio, una página de búsqueda o la página de destino de una sección de blog. Debido a que estas páginas tienen muchas plantillas, almacenamos las plantillas en la carpeta _generated y las construimos desde allí en lugar de tener archivos HTML o Markdown individuales para cada una. Estas carpetas tienen un prefijo con un guión bajo para indicar que no generan páginas directamente debajo de ellas, sino que se utilizan para crear páginas en otros lugares.

A continuación, ¡subdirectorios l10n! Cada directorio debe tener el nombre de la etiqueta de idioma BCP47 (más comúnmente, el código de configuración regional) para la localización que contiene: por ejemplo, en para inglés o en-US para inglés americano. En el código base de chromeOS.dev, a menudo también nos referimos a estos como locales . Estas carpetas se convertirán en los subdirectorios de localización, segmentando el contenido a una localización. La cascada de datos de 11ty permite que los datos estén disponibles para cada archivo en un directorio y sus hijos si el archivo está en la raíz de un directorio y tiene el mismo nombre que el directorio (llamados archivos de datos de directorio). 11ty usa un objeto devuelto de este archivo, o una función que devuelve un objeto, y lo inyecta en las variables disponibles para la creación de plantillas, por lo que tenemos acceso a los datos aquí para todo el contenido de esa localización.

Para ayudar en la capacidad de mantenimiento de estos archivos, escribimos un asistente llamado l10n-data , parte de nuestro andamiaje de sitio estático, que aprovecha esta estructura de carpetas para construir una cascada de datos localizados, lo que permite que los datos se localicen poco a poco. Hace esto al tener datos almacenados en un directorio de datos específico de la localidad, directorio _data en él (cargado en el archivo de datos del directorio). Si busca en nuestro directorio de datos locales en inglés, por ejemplo, verá modelos de microcopia como locale.json que define el código de idioma y la dirección de escritura que luego se representará en nuestro HTML, newsletter.yml que define la microcopia necesaria para nuestro suscripción al boletín y un archivo microcopy.yml que incluye microcopias generales utilizadas en varios lugares del sitio que no caben en un archivo más específico. Dondequiera que se use alguna de estas microcopias, las extraemos de estos datos disponibles a través de 11ty inyectando variables de datos en nuestras plantillas para usar.

La microcopia tiende a ser la más difícil de administrar, mientras que el resto del contenido es en su mayoría sencillo. Coloque su contenido, a menudo archivos Markdown o HTML, en la subcarpeta localizada. Para los generadores de sitios estáticos que funcionan en la estructura de carpetas, el nombre de archivo y la estructura de carpetas del contenido generalmente se asignarán 1:1 a la URL final de ese contenido, por lo que un archivo Markdown en en/web/pwas.md generaría una URL. en/web/pwa . Siguiendo nuestro principio de localización de "valores, no claves", decidimos que no localizaríamos los nombres de los archivos de contenido (y, por lo tanto, las rutas), lo que nos facilita el seguimiento del estado de localización del mismo archivo en todas las configuraciones regionales y para que los usuarios lo sepan. están en la página correcta entre diferentes lugares.

Ayudantes I18n

Además del contenido y la microcopia, descubrimos que necesitábamos escribir una serie de módulos auxiliares para facilitar el trabajo con contenido localizado. 11ty tiene un concepto llamado filtro que permite modificar el contenido antes de renderizarlo. Terminamos construyendo cuatro de ellos para ayudar con las plantillas de i18n.

El primero es un filtro de fecha. Estandarizamos tener todas las fechas en nuestro contenido escritas como un valor de fecha YAML porque principalmente las escribimos en YAML y están disponibles en nuestras plantillas como una marca de tiempo UTC completa. Cuando se usa el módulo y la configuración full-icu , la cadena de fecha (el contenido que se cambia), junto con el código de configuración regional para el contenido que se representa, se puede pasar directamente a Date.toLocaleString (con opciones de formato opcionales) para representar una fecha localizada. Date.toLocaleDateString se puede usar opcionalmente en su lugar si solo desea la parte de la fecha cuando no se pasan opciones de formato, en lugar de la fecha y hora completas localizadas.

El segundo filtro es algo que llamamos localURL . Esto toma una URL local (contenido que se cambia) y la configuración regional en la que debería estar la URL, y los intercambia. Cambia, por ejemplo, /en/linux a /es/linux .

Los últimos dos filtros tratan sobre la recuperación de información localizada solo del código local. El tercero aprovecha el módulo iso-639-10 para transformar un código de configuración regional en un nombre de idioma en el idioma nativo. Esto lo usamos principalmente para nuestro selector de idioma. El cuarto usa el módulo iso-i18n-countries para recuperar una lista de países en ese idioma. Esto lo usamos principalmente para crear formularios con listas de países.

Además de los filtros, 11ty tiene un concepto llamado colecciones que es una agrupación de contenido. 11ty hace que varias colecciones estén disponibles de forma predeterminada e incluso puede crear colecciones a partir de etiquetas. En un sitio multilingüe, descubrimos que queríamos crear colecciones personalizadas. Terminamos creando una serie de funciones auxiliares para crear colecciones basadas en la localización. Esto nos permite hacer cosas como tener colecciones de etiquetas específicas de la ubicación o colecciones de secciones del sitio sin necesidad de filtrar nuestras plantillas contra todo el contenido de nuestro sitio.

Nuestro ayudante final y más crítico fueron los datos globales de nuestro sitio. Basándose en la estructura de subdirectorios basada en el código local, esta función determina dinámicamente qué localizaciones admite el sitio. Construye una variable global, site , que incluye la propiedad l10n , que contiene todo el contenido específico de localización y microcopia de {{locale-code}}.11tydata.js . También contiene una propiedad de languages que enumera todas las configuraciones regionales disponibles como una matriz. Finalmente, la función genera un archivo JavaScript que detalla qué idiomas admite el sitio y archivos individuales para cada entrada en {{locale-code}}.11tydata.js , con clave por localización, todo diseñado para ser importado por nuestras secuencias de comandos del navegador. El trabajo pesado de este archivo vincula nuestro sitio estático con nuestro JavaScript front-end con la única fuente de verdad que es la información de localización que ya necesitamos. También nos permite generar páginas programáticamente basadas en nuestras localizaciones al site.l10n . Esto, combinado con nuestras colecciones específicas de localización, nos permite usar la paginación de 11ty para crear páginas de inicio y de noticias localizadas sin mantener páginas HTML separadas para cada una.

Conclusión

Conseguir que la internacionalización y la localización sean correctas puede ser difícil; Comprender cómo las diferentes estrategias y afectan la complejidad es fundamental para hacerlo más fácil. Elija una estrategia de i18n que se adapte naturalmente a los sitios estáticos, subdirectorios, luego cree herramientas a partir de eso para automatizar partes de i18n e i10n a partir del contenido que se produce. Cree modelos sólidos de contenido y microcopia. Aproveche los trabajadores de servicio para la localización independiente del servidor. Átelo todo junto con un diseño que responda no solo al tamaño de la pantalla, sino también al contenido. Al final, tendrá un sitio que les encantará a los usuarios de todas las configuraciones regionales y que los autores y traductores pueden mantener como si fuera un sitio simple de una sola configuración regional.