Internationalisation et localisation pour les sites statiques

L'internationalisation et la localisation ne se limitent pas à la rédaction de votre contenu en plusieurs langues. Vous avez besoin d'une stratégie pour déterminer quelle localisation envoyer et du code pour le faire. Vous devez être en mesure de prendre en charge non seulement différentes langues, mais également différentes régions avec la même langue. Votre interface utilisateur doit être réactive, non seulement à la taille de l'écran, mais également aux différentes langues et modes d'écriture. Votre contenu doit être structuré, jusqu'à la microcopie de votre interface utilisateur et le format de vos dates, pour être adaptable à n'importe quelle langue que vous lui lancez. Faire tout cela avec un générateur de site statique, comme Eleventy, peut rendre les choses encore plus difficiles, car vous n'avez peut-être pas de base de données, mais un serveur. Tout peut être fait, cependant, mais cela demande de la planification.

Lors de la création de chromeOS.dev, nous savions que nous devions le rendre accessible à un public mondial. S'assurer que notre base de code peut prendre en charge plusieurs paramètres régionaux (langue, région ou combinaison des deux) sans avoir besoin de coder chacun sur mesure, tout en permettant à la traduction d'être effectuée avec le moins de connaissances possible sur ce système, serait essentiel pour faire ça arrive. Nos créateurs de contenu devaient pouvoir se concentrer sur la création de contenu, et nos traducteurs sur la traduction de contenu, avec le moins de travail possible pour intégrer leur travail au site et le déployer. Répondre à ces besoins parfois contradictoires est au cœur de ce qu'il faut pour internationaliser les bases de code et localiser les sites.

L'internationalisation (i18n) et la localisation (l10n) sont les deux faces d'une même médaille. L'internationalisation concerne la manière dont, dans notre cas, le logiciel est conçu de manière à pouvoir être adapté à plusieurs langues et régions sans nécessiter de modifications techniques. La localisation, en revanche, consiste à adapter le logiciel à ces langues et régions. L'internationalisation peut se produire sur l'ensemble de la pile de sites Web ; de HTML, CSS et JS pour concevoir des considérations et créer des systèmes. La localisation se produit principalement dans la création de contenu (à la fois copie longue et microcopie) et la gestion.

Note : Pour les curieux, i18n et l10n sont des types d'abréviations appelés numéronymes. A11y, pour l'accessibilité, est un autre numéronyme courant dans le développement Web.

Internationalisation (i18n)

Lorsque vous déterminez l'internationalisation, vous devez généralement prendre en compte trois éléments : comment déterminer la langue et/ou la région souhaitée par l'utilisateur, comment vous assurer qu'il obtient le contenu dans sa localisation préférée et comment adapter votre site pour s'adapter à ces différences. Bien que les spécificités de mise en œuvre puissent changer pour les sites dynamiques (qui affichent une page lorsqu'un utilisateur la demande) et les sites statiques (où les pages sont créées avant d'être déployées), les concepts de base doivent rester les mêmes.

Détermination de la langue et de la région de l'utilisateur

La première chose à considérer lors de la détermination de l'internationalisation est de déterminer comment vous souhaitez que les utilisateurs accèdent au contenu localisé. Cette décision deviendra fondamentale pour la configuration d'autres systèmes. Il est donc important de prendre cette décision tôt et de s'assurer que les compromis fonctionnent bien pour vos utilisateurs.

En règle générale, il existe trois méthodes de haut niveau pour déterminer la localisation à proposer aux utilisateurs :

1. Localisation à partir de l'adresse IP ;
2. En-tête Accept-Language ou navigator.languages ​​;
3. Identifiant dans l'URL.

De nombreux systèmes finissent par combiner un, deux ou les trois, au moment de décider quelle localisation servir. Pendant que nous enquêtions, cependant, nous avons trouvé des problèmes avec l'utilisation des adresses IP et des en-têtes Accept-Language que nous pensions être suffisamment importants pour ne pas être pris en compte pour nous :

• La langue préférée d'un utilisateur ne correspond souvent pas à son emplacement physique, fourni par l'adresse IP. Ce n'est pas parce qu'une personne se trouve physiquement en Amérique, par exemple, qu'elle préférerait un contenu en anglais.
• L'analyse de la localisation à partir des adresses IP est difficile, généralement peu fiable et peut empêcher le site d'être exploré par les moteurs de recherche.
• Les en-têtes Accept-Language ne sont souvent jamais explicitement définis et ne fournissent que des informations sur la langue, pas sur la région. En raison de ses limites, cela peut être utile pour établir une estimation initiale de la langue, mais n'est pas nécessairement fiable.

Pour ces raisons, nous avons décidé qu'il serait préférable pour nous de ne pas essayer de déduire la langue ou la région avant qu'un utilisateur n'arrive sur notre site, mais plutôt d'avoir des indicateurs forts dans nos URL. Avoir des indicateurs solides nous permet également de supposer qu'ils obtiennent le site dans la langue qu'ils veulent à partir de leur URL d'accès uniquement, fournit un moyen simple de partager directement du contenu localisé sans se soucier de la redirection et nous fournit un moyen propre de laisser les utilisateurs changent leur langue préférée.

Il existe trois modèles courants pour créer des identifiants dans les URL :

1. Fournir différents domaines (généralement des TLD ou des sous-domaines pour différentes régions et langues (par exemple example.com et example.de , en.example.org et de.example.org ) ;
2. Avoir des sous-répertoires localisés pour le contenu (par exemple example.com/en et example.com/de ) ;
3. Diffusez du contenu localisé en fonction des paramètres d'URL (par exemple, example.com?loc=en et example.com?loc=de ).

Bien qu'ils soient couramment utilisés, les paramètres d'URL ne sont généralement pas recommandés car il est difficile pour les utilisateurs de reconnaître la localisation (ainsi qu'un certain nombre de problèmes d'analyse et de gestion). Nous avons également décidé que différents domaines n'étaient pas une bonne solution pour nous ; notre site est une application Web progressive et chaque domaine, y compris les TLD et les sous-domaines, est considéré comme une origine différente, nécessitant effectivement une PWA distincte pour chaque localisation.

Nous avons décidé d'utiliser des sous-répertoires, ce qui nous a permis de localiser uniquement la langue ( example.com/en ) ou la langue et la région ( example.com/en-US et example.com/en-GB ) selon les besoins tout en maintenir une seule PWA. Nous avons également décidé que chaque localisation de notre site vivrait dans un sous-répertoire afin qu'une langue ne soit pas élevée au-dessus d'une autre, et que toutes les URL, à l'exception du sous-répertoire, seraient identiques dans toutes les localisations en fonction de la langue de création, permettant aux utilisateurs de changer facilement localisations sans avoir besoin de traduire les URL.

Servir du contenu localisé

Une fois qu'une stratégie pour déterminer la langue et la région d'un utilisateur a été déterminée, vous avez besoin d'un moyen de lui proposer de manière fiable le bon contenu. Au minimum, cela nécessitera une certaine forme d'informations stockées, que ce soit dans un cookie, un stockage local ou une partie de la logique personnalisée de votre application. Pouvoir conserver les préférences de localisation d'un utilisateur est une partie importante de l'expérience utilisateur d'i18n ; Si un utilisateur a identifié qu'il voulait du contenu en allemand et qu'il atterrit sur du contenu en anglais, vous devriez être en mesure d'identifier sa langue préférée et de le rediriger de manière appropriée. Cela peut être fait sur le serveur, mais la solution que nous avons choisie pour chromeOS.dev est indépendante de l'hébergement et de la configuration du serveur : nous avons utilisé des service workers. Le parcours de l'utilisateur est le suivant :

• Un utilisateur vient sur notre site pour la première fois. Notre service worker n'est pas installé.
• Quelle que soit la localisation sur laquelle ils atterrissent, nous définissons leur langue préférée dans IndexedDB. Pour cela, nous supposons qu'ils y atterrissent par un moyen, social, de référence ou de recherche, qui les a dirigés en fonction d'autres contextes de localisation que nous n'avons pas. Si un utilisateur atterrit sans ensemble de localisation, nous le définissons sur l'anglais, car c'est la langue principale de notre site. Nous avons également un sélecteur de langue dans notre pied de page pour permettre à un utilisateur de changer de langue. À ce stade, notre service worker doit être installé.
• Une fois le service worker installé, nous interceptons toutes les demandes d'URL pour la navigation sur le site. Parce que nos localisations sont basées sur des sous-répertoires, nous pouvons facilement identifier quelle localisation est demandée. Une fois identifiée, nous vérifions si la page demandée se trouve dans un sous-répertoire localisé, vérifions si le sous-répertoire localisé se trouve dans une liste de localisations prises en charge et vérifions si le sous-répertoire localisé correspond à leurs préférences stockées dans IndexedDB. Si ce n'est pas dans un sous-répertoire localisé ou si le sous-répertoire localisé correspond à leurs préférences, nous servons la page ; sinon, nous effectuons une redirection 302 de notre agent de service pour la bonne localisation.

Nous avons regroupé notre solution dans le plug-in Workbox, Service Worker Internationalization Redirect. Le plug-in, ainsi que son sous-module de préférences, peuvent être combinés pour définir et obtenir la préférence de langue d'un utilisateur et gérer la redirection lorsqu'il est combiné avec la méthode registerRoute de Workbox et le filtrage des demandes sur request.mode === 'navigate' .

Un exemple complet et minimal ressemble à ceci :

Code client

 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 } });

Code de travailleur de service

 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), );

Avec la combinaison du code côté client et du service worker, la localisation préférée des utilisateurs sera automatiquement définie lorsqu'ils accèderont au site pour la première fois et, s'ils naviguent vers une URL qui ne figure pas dans leurs localisations préférées, ils seront redirigé.

Adaptation de l'interface utilisateur du site

Il y a beaucoup de choses à faire pour adapter correctement les interfaces utilisateur, donc même si tout ne sera pas couvert ici, il y a une poignée de choses plus subtiles qui peuvent et doivent être gérées par programme.

Citations en bloc

Un modèle de conception courant consiste à avoir des guillemets en bloc entourés de guillemets, mais saviez-vous que ce qui est utilisé pour ces guillemets varie selon la localisation ? Au lieu de coder en dur, utilisez open-quote close-quote pour vous assurer que les guillemets corrects sont utilisés pour la langue correcte.

Format de date et de nombre

Les dates et les nombres ont une méthode, .toLocaleString pour permettre le formatage basé sur une localisation (langue et/ou région). Les navigateurs qui les prennent en charge sont livrés avec toutes les localisations disponibles, ce qui les rend facilement utilisables là-bas, mais pas Node.js. Heureusement, le module full-icu pour Node vous permet d'utiliser toutes les données de localisation disponibles. Pour ce faire, après avoir installé le module, exécutez votre code avec la variable d'environnement NODE_ICU_DATA définie sur le chemin d'accès au module, par exemple NODE_ICU_DATA=node_modules/full-icu .

Méta-informations HTML

Trois zones de votre balise HTML et de vos en-têtes doivent être mises à jour à chaque localisation :

• La langue de la page,
• Direction d'écriture,
• Langues alternatives dans lesquelles la page est disponible.

Le premier à aller sur l'élément html avec les propriétés dir et lang respectivement, par exemple <html lang="en" dir-"ltr"> pour l'anglais américain. Une configuration correcte de ces paramètres garantira que le contenu circule dans la bonne direction et peut permettre aux navigateurs de comprendre la langue dans laquelle se trouve la page, permettant des fonctionnalités supplémentaires telles que la traduction du contenu. Vous devez également inclure des liens <link href="/es" rel="alternate" hreflang="es"> rel="alternate" pour informer les moteurs de recherche qu'une page a été entièrement traduite. faites savoir aux moteurs de recherche que cela a une traduction qu'il devrait rechercher.

Conception intrinsèque

La localisation du contenu peut présenter des défis de conception car différentes traductions occupent une place variable sur la page. Certaines langues, comme l'allemand, ont des mots plus longs nécessitant plus d'espace horizontal ou un habillage de texte plus indulgent. D'autres langues, comme l'arabe, ont des polices de caractères plus hautes nécessitant plus d'espace vertical. Heureusement, il existe un certain nombre d'outils CSS pour adapter l'espacement et la mise en page non seulement à la taille de la fenêtre d'affichage, mais également au contenu, ce qui signifie qu'ils s'adaptent mieux à plusieurs langues.

Il existe un certain nombre d'unités CSS spécialement conçues pour travailler avec du contenu. Les unités em et rem représentent respectivement la taille de police calculée et la taille de police racine. L'échange de valeurs px de taille fixe pour ces unités peut grandement contribuer à rendre un site plus réactif à son contenu. Ensuite, il y a l'unité ch , représentant la taille en ligne du glyphe 0 (zéro) dans une police. Cela vous permet de lier des choses comme width , par exemple, directement au contenu qu'il contient.

Ces unités peuvent ensuite être combinées avec des outils CSS puissants et existants pour la mise en page, en particulier flexbox et grille, pour des composants qui s'adaptent à leur taille, et les mises en page s'adaptent à leur contenu. En améliorant ceux avec des propriétés logiques pour les bordures, les marges et le remplissage au lieu de propriétés physiques physiques, ces mises en page et composants s'adaptent également automatiquement au mode d'écriture. La puissance de la conception Web intrinsèque (inventée par Jen Simmons, les unités sensibles au contenu et les propriétés logiques permettent de concevoir et de construire des interfaces afin qu'elles puissent s'adapter à n'importe quelle langue, pas seulement à n'importe quelle taille d'écran.

Localisation (l10n)

La forme la plus évidente que prend la localisation est la traduction du contenu d'une langue à une autre. Sous des formes plus subtiles, les traductions ne se font pas seulement par langue, mais aussi par région, par exemple, l'anglais parlé en américain par rapport à l'anglais parlé au Royaume-Uni, en Afrique du Sud ou en Australie. Pour réussir ici, il est essentiel de comprendre ce qu'il faut traduire et comment structurer votre contenu pour la traduction.

Stratégie de contenu

Certaines parties d'un projet logiciel sont importantes à localiser et d'autres non. Les noms de classe CSS, les variables JavaScript et d'autres endroits de votre base de code qui sont structurels, mais non accessibles à l'utilisateur, n'ont probablement pas besoin d'être localisés. Déterminer ce qui doit être localisé et comment le structurer revient à la stratégie de contenu.

La stratégie de contenu a de nombreuses définitions, mais ici, cela signifie la structure du contenu, la microcopie (les mots et les phrases utilisés tout au long d'un projet non liés à un élément de contenu spécifique) et leurs connexions. Pour des informations plus détaillées sur la stratégie de contenu, je recommanderais Content Strategy for Mobile de Karen McGrane et Designing Connected Content de Carrie Hane et Mike Atherton.

Pour chromeOS.dev, nous avons fini par codifier des modèles de contenu qui décrivent la structure de notre contenu. Les modèles de contenu ne sont pas réservés aux contenus longs de type article ; un modèle de contenu doit exister pour toute entité qu'un utilisateur peut spécifiquement vouloir de vous, comme un auteur, un document ou même des ressources multimédias réutilisables. Les bons modèles de contenu incluent des morceaux adressables individuellement, ou des morceaux, d'un morceau conceptuel plus grand, tout en excluant les morceaux qui sont tangentiellement liés ou peuvent être référencés à partir d'un autre modèle de contenu. Par exemple, un modèle de contenu pour un article de blog peut inclure un titre, un tableau de balises, une référence à un auteur, la date de publication et le corps de l'article, mais il ne doit pas inclure la chaîne de fil d'Ariane ou le le nom et l'image de l'auteur, qui devrait être son propre modèle de contenu. Les modèles de contenu ne changent pas d'une localisation à l'autre ; ils sont la structure du site. Une instance d'un modèle de contenu est liée à une localisation, et ces instances peuvent être localisées.

Cependant, les modèles de contenu ne couvrent qu'une partie de ce qui doit être localisé. Le reste - vos boutons "Lire la suite", votre titre "Menu", votre texte de clause de non-responsabilité - c'est tout en microcopie. La microcopie a également besoin de structure. Alors que les modèles de contenu peuvent sembler naturels à créer, en particulier pour les sites basés sur des modèles, les modèles de microcopie ont tendance à être moins évidents et sont souvent négligés accidentellement en écrivant ce qui est nécessaire directement dans un modèle.

En créant des modèles de contenu et de microcopie et en les appliquant (par le biais d'un système de gestion de contenu, d'un filtrage ou d'une révision), vous êtes en mesure de vous assurer que la localisation peut se concentrer sur la localisation.

Localiser les valeurs, pas les clés

Les modèles de contenu et de microcopie génèrent généralement des structures apparentées à des objets dans une base de code ; qu'il s'agisse d'entrées de base de données, d'objet JSON, de YAML ou de Front Matter. Ne localisez pas les clés d'objet ! Si votre microcopie de texte de recherche se trouve dans un objet de microcopy à microcopy.search.text , ne la mettez pas dans un objet de microcopie à microcopie.chercher.texte . Les clés des modules doivent être traitées comme des identifiants indépendants de la localisation afin qu'elles puissent être utilisées de manière fiable dans des modèles réutilisables et utilisées dans une base de code. Cela signifie également que les clés d'objet ne doivent pas être présentées aux utilisateurs finaux sous forme de contenu ou de microcopie.

Configuration du site statique

Pour chromeOS.dev, nous avons utilisé Eleventy (11ty) avec Nunjucks comme générateur de site statique, mais ces recommandations pour la configuration d'un générateur de site statique devraient s'appliquer à la plupart des générateurs de site statique. Là où quelque chose est 11ty spécifique, il sera appelé.

Structure des dossiers

Les générateurs de sites statiques qui compilent en fonction de la structure des dossiers sont particulièrement efficaces pour prendre en charge la méthode i18n du sous-répertoire. 11ty prend également en charge une cascade de données avec des données globales et un moyen de générer des pages à partir de données via la pagination. Ainsi, la combinaison de ces trois concepts donne une structure de dossiers de base qui ressemble à ceci :

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

Au niveau supérieur, il existe un répertoire contenant les pages d'un site, appelé ici pages . Niché à l'intérieur, il y a un dossier _data contenant des fichiers de données globales. Ce dossier est important lorsque nous parlerons ensuite des assistants. Ensuite, il y a un dossier _generated . Nous avons un certain nombre de pages qui, au lieu d'avoir leur propre contenu, sont générées à partir de contenu existant, de petites quantités de microcopies ou d'une combinaison des deux. Pensez à une page d'accueil, une page de recherche ou la page de destination d'une section de blog. Étant donné que ces pages sont fortement basées sur des modèles, nous stockons les modèles dans le dossier _generated et les construisons à partir de là au lieu d'avoir des fichiers HTML ou Markdown individuels pour chacun. Ces dossiers sont précédés d'un trait de soulignement pour indiquer qu'ils ne génèrent pas de pages directement en dessous, mais sont plutôt utilisés pour créer des pages ailleurs.

Ensuite, les sous-répertoires l10n ! Chaque répertoire doit être nommé d'après la balise de langue BCP47 (plus communément, le code de paramètres régionaux) pour la localisation qu'il contient : par exemple, en pour l'anglais ou en-US pour l'anglais américain. Dans la base de code chromeOS.dev, nous les appelons également souvent locales . Ces dossiers deviendront les sous-répertoires de localisation, segmentant le contenu en une localisation. La cascade de données de 11ty permet aux données d'être disponibles pour chaque fichier d'un répertoire et ses enfants si le fichier est à la racine d'un répertoire et porte le même nom que le répertoire (appelé fichiers de données de répertoire). 11ty utilise un objet renvoyé par ce fichier, ou une fonction qui renvoie un objet, et l'injecte dans les variables mises à disposition pour la modélisation, nous avons donc accès aux données ici pour tout le contenu de cette localisation.

Pour faciliter la maintenabilité de ces fichiers, nous avons écrit un assistant appelé l10n-data , qui fait partie de notre échafaudage de site statique, qui tire parti de cette structure de dossiers pour créer une cascade de données localisées, permettant aux données d'être localisées au coup par coup. Pour ce faire, les données sont stockées dans un répertoire de données spécifique aux paramètres régionaux, le répertoire _data (chargé dans le fichier de données du répertoire). Si vous regardez dans notre répertoire de données de paramètres régionaux anglais, par exemple, vous verrez des modèles de microcopie comme locale.json qui définit le code de langue et le sens d'écriture qui seront ensuite rendus dans notre HTML, newsletter.yml qui définit la microcopie nécessaire pour notre l'inscription à la newsletter et un fichier microcopy.yml qui comprend une microcopie générale utilisée à plusieurs endroits sur le site et qui ne rentre pas dans un fichier plus spécifique. Partout où une partie de cette microcopie est utilisée, nous la tirons de ces données mises à disposition via 11ty en injectant des variables de données dans nos modèles à utiliser.

La microcopie a tendance à être la plus difficile à gérer, tandis que le reste du contenu est généralement simple. Placez votre contenu, souvent des fichiers Markdown ou HTML, dans le sous-dossier localisé. Pour les générateurs de sites statiques qui fonctionnent sur la structure de dossiers, le nom de fichier et la structure de dossiers du contenu seront généralement mappés 1: 1 à l'URL finale de ce contenu, de sorte qu'un fichier Markdown à en/web/pwas.md sortira vers une URL en/web/pwa . Conformément à notre principe de localisation "des valeurs, pas des clés", nous avons décidé de ne pas localiser les noms de fichiers de contenu (et donc les chemins), ce qui nous permet de suivre plus facilement l'état de localisation du même fichier dans les paramètres régionaux et pour les utilisateurs de savoir ils sont sur la bonne page entre les différents paramètres régionaux.

Aides I18n

En plus du contenu et de la microcopie, nous avons constaté que nous devions écrire un certain nombre de modules d'assistance pour faciliter le travail avec le contenu localisé. 11ty a un concept appelé filtre qui permet de modifier le contenu avant de le rendre. Nous avons fini par en construire quatre pour aider à la création de modèles i18n.

Le premier est un filtre de date. Nous avons normalisé l'écriture de toutes les dates de notre contenu sous forme de valeur de date YAML, car nous les écrivons principalement en YAML et elles deviennent disponibles dans nos modèles sous la forme d'un horodatage UTC complet. Lors de l'utilisation du module et de la configuration full-icu , la chaîne de date (contenu en cours de modification), ainsi que le code de paramètres régionaux pour le contenu en cours de rendu, peuvent être passés directement à Date.toLocaleString (avec des options de formatage facultatives) pour rendre une date localisée. Date.toLocaleDateString peut éventuellement être utilisé à la place si vous souhaitez uniquement la partie date lorsqu'aucune option de formatage n'est transmise, au lieu de la date et de l'heure localisées complètes.

Le deuxième filtre est quelque chose que nous avons appelé localURL . Cela prend une URL locale (contenu en cours de modification) et les paramètres régionaux dans lesquels l'URL doit se trouver, et les permute. Il change, par exemple, /en/linux en /es/linux .

Les deux derniers filtres concernent la récupération d'informations localisées à partir du code de paramètres régionaux uniquement. Le troisième exploite le module iso-639-10 pour transformer un code de locale en nom de langue dans la langue maternelle. Nous l'utilisons principalement pour notre sélecteur de langue. Le quatrième utilise le module iso-i18n-countries pour récupérer une liste de pays dans cette langue. Nous l'utilisons principalement pour créer des formulaires avec des listes de pays.

En plus des filtres, 11ty a un concept appelé collections qui est un regroupement de contenu. 11ty rend un certain nombre de collections disponibles par défaut et peut même créer des collections à partir de balises. Dans un site multilingue, nous avons constaté que nous voulions créer des collections personnalisées. Nous avons fini par créer un certain nombre de fonctions d'assistance pour créer des collections basées sur la localisation. Cela nous permet de faire des choses comme avoir des collections de balises spécifiques à un emplacement ou des collections de sections de site sans avoir besoin de filtrer dans nos modèles tout le contenu de notre site.

Notre dernière aide, et la plus critique, était les données globales de notre site. S'appuyant sur la structure de sous-répertoires basée sur le code local, cette fonction détermine dynamiquement les localisations prises en charge par le site. Il construit une variable globale, site , qui inclut la propriété l10n , contenant tout le contenu spécifique à la microcopie et à la localisation de {{locale-code}}.11tydata.js . Il contient également une propriété languages ​​qui répertorie tous les paramètres régionaux disponibles sous forme de tableau. Enfin, la fonction génère un fichier JavaScript détaillant les langues prises en charge par le site et des fichiers individuels pour chaque entrée dans {{locale-code}}.11tydata.js , codés par localisation, tous conçus pour être importés par nos scripts de navigateur. La lourde charge de ce fichier lie notre site statique à notre JavaScript frontal, la seule source de vérité étant les informations de localisation dont nous avons déjà besoin. Cela nous permet également de générer par programme des pages basées sur nos localisations en bouclant sur site.l10n . Ceci, combiné à nos collections spécifiques à la localisation, nous permet d'utiliser la pagination de 11ty pour créer des pages d'accueil et d'actualités localisées sans conserver de pages HTML distinctes pour chacune.

Conclusion

Obtenir une internationalisation et une localisation correctes peut être difficile ; comprendre comment différentes stratégies et affectent la complexité est essentiel pour faciliter les choses. Choisissez une stratégie i18n qui convient naturellement aux sites statiques, aux sous-répertoires, puis créez des outils à partir de cela pour automatiser des parties d'i18n et d'i10n à partir du contenu en cours de production. Créez des modèles de contenu et de microcopie robustes. Tirez parti des techniciens de service pour une localisation indépendante du serveur. Associez le tout à un design qui s'adapte non seulement à la taille de l'écran, mais aussi au contenu. En fin de compte, vous aurez un site que vos utilisateurs de toutes les régions vont adorer et qui peut être maintenu par les auteurs et les traducteurs comme s'il s'agissait d'un simple site à une seule région.