Internationalisation et localisation pour les sites statiques

À propos de l'auteur

Sam Richard, mieux connu sous le nom de Snugug sur Internet, est un développeur avec des tendances en matière de design et un amour de la création d'outils open source pour aider les deux. …
En savoir plus sur
Sam
…

L'internationalisation et la localisation ne se limitent pas à rédiger votre contenu dans plusieurs langues. Vous avez besoin d'une stratégie pour déterminer la localisation à envoyer et du code pour le faire. Vous devez pouvoir 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 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 quel langage 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 néanmoins de serveur. Cependant, tout peut être fait, mais il faut de la planification.

Lors de la construction de chromeOS.dev nous savions que nous devions le rendre disponible à un public mondial. S'assurer que notre base de code puisse prendre en charge plusieurs paramètres régionaux (langue, région ou combinaison des deux) sans avoir à coder chacun d'eux, tout en permettant la traduction avec le moins de connaissances possible de 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 sur le site et le déployer. Obtenir 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 consiste à savoir comment, dans notre cas, le logiciel est conçu de manière à pouvoir être adapté à plusieurs langues et régions sans nécessiter de changements d'ingénierie. La localisation, en revanche, consiste à adapter le logiciel à ces langues et régions. L'internationalisation peut se produire sur toute la pile de sites Web; depuis HTML, CSS et JS pour concevoir des considérations et construire des systèmes. La localisation se produit principalement dans la création de contenu (à la fois copie longue et microcopie) et la gestion. . A11y, pour l'accessibilité, est un autre numonyme courant dans le développement Web.

Internationalisation (i18n)

Lors de la détermination de l'internationalisation, il y a généralement trois éléments dont vous devez tenir compte: comment déterminer la langue et / ou la région de l'utilisateur veut, comment s'assurer qu'ils obtiennent du contenu dans leur localisation préférée et comment adapter votre site pour s'adapter à ces différences. Bien que les spécificités de l'implémentation puissent changer pour les sites dynamiques (qui affichent une page lorsqu'un utilisateur le demande) et les sites statiques (où les pages sont avant d'être déployées), les concepts de base doivent rester les mêmes.

Determining User Language And Region

La première chose à considérer lors de la détermination de l'internationalisation est de déterminer comment vous voulez que les utilisateurs accèdent au contenu localisé. Cette décision deviendra fondamentale pour la configuration des autres systèmes, il est donc important de le décider tôt et de vous 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 à servir. users:

1. Location from IP address;
2. Accept-Language header or navigator.languages ​​;
3. Identifier in URL.

De nombreux systèmes finissent par combiner un, deux, ou les trois, au moment de décider quelle localisation servir. Cependant, au cours de notre enquête, nous avons trouvé des problèmes avec l'utilisation des adresses IP et des en-têtes Accept-Language que nous pensions suffisamment importants pour nous soustraire à notre considération:

• La langue préférée d'un utilisateur ne correspond souvent pas. à leur emplacement physique, que l'adresse IP fournit. Le simple fait qu'une personne se trouve physiquement en Amérique, par exemple, ne signifie pas qu'elle préférerait le contenu anglais.
• L'analyse de l'emplacement à partir des adresses IP est difficile, généralement peu fiable et peut empêcher l'exploration du site par les moteurs de recherche. .
• Les en-têtes Accept-Language sont souvent jamais définis explicitement et ne fournissent que des informations sur la langue, pas la région. En raison de ses limites, cela peut être utile pour établir une première estimation 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 une l'utilisateur arrive sur notre site, mais a plutôt 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 souhaitent à partir de leur URL d'accès uniquement, fournissent un moyen facile de partager du contenu localisé directement sans souci de redirection et nous fournissent un moyen propre de laisser les utilisateurs changent de langue préférée.

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

1. Fournissez différents domaines (généralement TLDs ou sous-domaines pour différentes régions et langues (par exemple) example.com et example.de en.example.org et de.example.org );
2. Ont localisé sous-répertoires pour le contenu (par exemple example.com/en et example.com/de );
3. Servir 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 sont e n'est généralement pas recommandé 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 Progressive Web App et chaque domaine, y compris les TLD et sous-domaines, est considéré comme une origine différente nécessitant en fait une PWA distincte pour chaque localisation.

Nous avons décidé d'utiliser sous-répertoires, ce qui nous a permis de localiser uniquement sur 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 conservant 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 les localisations basées sur la langue de création, permettant aux utilisateurs de changer facilement localisations sans avoir besoin de traduire les URL.

Diffusion de contenu localisé

Une fois que la stratégie de détermination de la langue et de la région d'un utilisateur a été déterminée, vous devez trouver 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. Être capable de conserver les préférences de localisation d'un utilisateur est une partie importante de l'expérience utilisateur i18n; si un utilisateur a identifié qu'il veut du contenu en allemand et qu'il atterrit sur du contenu 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é service workers . Le parcours de l’utilisateur est le suivant:

• Un utilisateur se rend sur notre site pour la première fois. Notre technicien de service n’est pas installé.
• Quelle que soit la localisation sur laquelle ils atterrissent, nous définissons comme langue préférée dans IndexedDB . Pour cela, nous supposons qu'ils y atterrissent par un moyen (social, référent ou recherche) qui les a orientés en fonction d'autres contextes de localisation que nous n'avons pas. Si un utilisateur arrive sans définition 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 le site navigation . Comme nos localisations sont basées sur des sous-répertoires, nous pouvons facilement identifier la localisation demandée. Une fois identifiée, nous vérifions si la page demandée est dans un sous-répertoire localisé, vérifions si le sous-répertoire localisé est 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 service worker pour la bonne localisation.

Nous avons regroupé notre solution dans Workbox plugin, Service Worker Internationalization Redirect . Le plugin, ainsi que son sous-module de préférences peut être combiné 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 les requêtes de filtrage sur request.mode === 'naviguer' .

Un exemple complet et minimal ressemble à ceci:

Code client

 import {preferences} from 'service-worker-i18n-redirect / preferences';
window.addEventListener ('DOMContentLoaded', async () => {
  const language = wait preferences.get ('lang');
  if (language === undefined) {
    preferences.set ('lang', lang.value); // Langue déterminée à partir de la localisation sur laquelle l'utilisateur a atterri
  }
});

Service Worker Code

 import {StaleWhileRevalidate} de 'workbox-stratégies';
import {CacheableResponsePlugin} depuis 'workbox-cacheable-response';
import {i18nHandler} depuis 'service-worker-i18n-redirect';
import {preferences} depuis 'service-worker-i18n-redirect / preferences';
import {registerRoute} de 'workbox-routing';

// Créer une stratégie de mise en cache
const htmlCachingStrategy = new StaleWhileRevalidate ({
  cacheName: 'pages-cache',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [200],
    }),
  ],
});

// Tableau de localisations prises en charge
langues const = ['en', 'es', 'fr', 'de', 'ko'];

// Utilisez-le pour les navigations
registerRoute (
  ({request}) => request.mode === 'naviguer',
  i18nHandler (langues, préférences, 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 lors de leur première visite sur le site et, s’ils naviguent vers une URL qui ne figure pas dans leurs localisations préférées, ils

Adapter l'interface utilisateur du site

Il y a beaucoup de choses à faire pour adapter correctement les interfaces utilisateur, donc bien que tout ne soit pas couvert ici, il y a une poignée de choses plus subtiles qui peuvent et doivent être gérées

Blockquote Quotes

Un modèle de conception courant consiste à placer des blockquotes entre guillemets, mais saviez-vous que ce qui est utilisé pour ces guillemets varie selon la localisation? Au lieu d'un codage en dur, utilisez open-quote et close-quote pour vous assurer que les guillemets corrects sont utilisés pour la langue correcte.

Format de date et de numéro

Les deux dates et nombres ont une méthode, .toLocaleString pour autoriser mise en forme basée 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 Node.js ne le fait pas. 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 ex. NODE_ICU_DATA = node_modules / full-icu .

HTML Meta Information

Il y a trois zones dans votre balise HTML et les en-têtes qui doivent être mis à jour à chaque localisation:

• La langue de la page,
• ] Direction d'écriture,
• Autres langues 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 pour l'anglais américain. Si vous les définissez correctement, vous garantissez que le contenu circule dans la bonne direction et peut permettre aux navigateurs de comprendre la langue de la page, ce qui permet des fonctionnalités supplémentaires telles que la traduction du contenu. Vous devez également inclure des liens rel = "Alternate" pour informer les moteurs de recherche qu'une page a été entièrement traduite. Ainsi, inclure sur notre page de destination en anglais permettra aux moteurs de recherche de savoir qu'elle a une traduction.

Conception intrinsèque

La localisation du contenu peut présenter des défis de conception car différentes traductions prendront une quantité variable de place 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 rendre l'espacement et la mise en page sensibles 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çu pour travailler avec du contenu. Il existe les unités em et rem représentant respectivement la taille de police calculée et la taille de police racine. L'échange de valeurs de taille fixe px pour ces unités peut contribuer grandement à 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 éléments tels que width par exemple, directement au contenu qu'il contient .

Ces unités peuvent ensuite être combinées avec des outils CSS puissants existants pour la mise en page, en particulier flexbox et grid aux composants qui s'adaptent à leur taille et les mises en page s'adaptent à leur contenu. En améliorant ceux qui ont des propriétés logiques pour les bordures, les marges et le remplissage au lieu des propriétés physiques physiques, ces dispositions et composants s'adaptent automatiquement au mode d'écriture également. 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 quel langage, pas seulement n'importe quelle taille d'écran.

Localisation (l10n)

La forme la plus évidente de localisation est de traduire le 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 où elle est parlée, 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

Il y a quelques des parties d'un projet logiciel qu'il est important de localiser, et d'autres qui ne le sont pas. Les noms de classe CSS, les variables JavaScript et d'autres endroits de votre base de code qui sont structurels, mais qui ne sont pas destinés à l'utilisateur, n'ont probablement pas besoin d'être localisés. Figure

La stratégie de contenu a beaucoup de 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é à un élément de contenu spécifique), et leurs connexions. Pour des informations plus détaillées sur la stratégie de contenu, je recommande 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 uniquement destinés au contenu de type article long; 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 éléments adressables individuellement, ou des morceaux, d'un élément conceptuel plus grand, tout en excluant les morceaux qui sont liés de manière tangentielle 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 pour le 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 de la localisation à la localisation; 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.

Les modèles de contenu ne couvrent cependant qu'une partie de ce qui doit être localisé. Le reste – vos boutons "En savoir plus", le titre de votre "Menu", votre texte de clause de non-responsabilité – tout cela est une microcopie. La microcopie a également besoin de structure. Bien que la création de modèles de contenu puisse sembler naturelle, 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, de linting ou de révision: vous êtes en mesure de vous assurer que la localisation peut se concentrer sur la localisation.

Localize Values, Not Keys

Les modèles de contenu et de microcopie génèrent généralement des structures semblables à des objets dans une base de code; que ce soit des entrées de base de données, un objet JSON, YAML ou Front Matter . Ne localisez pas les clés d’objet! Si votre microcopie du texte de recherche se trouve dans un objet microcopie à microcopy.search.text ne la placez pas dans un objet microcopie à microcopie.chercher.texte . Les clés dans les modules doivent être traitées comme des identifiants indépendants de la localisation afin de pouvoir ê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 affichées aux utilisateurs finaux sous forme de contenu ou de microcopie.

Static Site Setup

Pour chromeOS.dev, nous avons utilisé Eleventy (11ty) avec Nunjucks comme notre générateur de site statique, mais ces recommandations pour la mise en place d'un générateur de site statique devraient être applicables à la plupart des générateurs de site statique. Là où quelque chose est spécifique à 11ty, 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 bons pour supporter la méthode du sous-répertoire i18n. 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 jusqu'à la pagination donc la combinaison de ces trois concepts donne une structure de dossier de base qui ressemble à ce qui suit:

.
└── pages
   ├── _data
   ├── _généré
   └── {{locale-code}}
      ├── {{local-code}}. 11tydata.js
      ├── _data
      └── [...content]

Au niveau supérieur, il existe un répertoire contenant les pages d'un site, appelé ici pages . Imbriqué à l'intérieur, il y a un dossier _data contenant les fichiers de données globales. Ce dossier est important lors de la prochaine discussion sur les 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 microcopie ou d'une combinaison des deux. Pensez à la page d'accueil d'une page d'accueil, d'une page de recherche ou de la page de destination d'une section de blog. Parce que ces pages sont hautement modélisées, 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 produisent pas de pages directement en dessous d’eux, mais sont plutôt utilisés pour créer des pages ailleurs.

Ensuite, l10n sous-répertoires! Chaque répertoire doit être nommé d'après la balise de langue BCP47 (plus communément, le code de localisation) 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 souvent locales . Ces dossiers deviendront les sous-répertoires de localisation, segmentant le contenu en une localisation. 11ty's data cascade permet aux données d'être disponibles pour chaque fichier dans un répertoire et ses enfants si le fichier est à la racine d'un répertoire et nommé de la même manière que le répertoire (appelé directory data files ). 11ty utilise un objet renvoyé par ce fichier, ou une fonction qui renvoie un objet, et l'injecte dans les variables disponibles pour la création de modèles, nous avons donc ici accès aux données pour tout le contenu de cette localisation.

Pour aider à 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 construire une cascade de données localisées, permettant aux données d'être localisé au coup par coup. Pour ce faire les données sont stockées dans un répertoire de données spécifique à la locale, répertoire _data (chargé dans le fichier de données du répertoire). Si vous regardez dans notre répertoire de données locales en anglais par exemple, vous verrez des modèles de microcopie comme locale.json qui définit le code de langue et la direction d'écriture qui seront ensuite rendus dans notre HTML, newsletter.yml qui définit la microcopie nécessaire pour l'inscription à notre newsletter, et un fichier microcopy.yml qui comprend une microcopie générale utilisée à plusieurs endroits du site et qui ne rentre pas dans un fichier plus spécifique. Partout où cette microcopie est utilisée, nous la tirons de ces données rendues disponibles grâce à l'injection de 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 des dossiers, le nom de fichier et la structure de dossiers du contenu mapperont généralement 1: 1 vers l'URL finale de ce contenu, donc un fichier Markdown à en / web / pwas.md afficherait une URL en / web / pwa . Suivant 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 que les utilisateurs le savent ils sont sur la bonne page entre 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'aide pour faciliter le travail avec du contenu localisé. 11ty a un concept appelé filtre qui permet au contenu d'être modifié avant d'être rendu. 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 standardisé le fait que toutes les dates de notre contenu soient écrites sous la forme d'une 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 du contenu en cours de rendu, peuvent être transmis directement à Date.toLocaleString (avec des options de mise en forme facultatives) pour rendre une date localisée. Date.toLocaleDateString peut éventuellement être utilisé à la place si vous voulez juste la partie de date lorsqu'aucune option de mise en forme 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 échange. 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 localisation uniquement. Le troisième s'appuie sur le module iso-639-10 pour transformer un code local 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 à filtrer dans nos modèles par rapport à tout le contenu de notre site.

Notre dernière aide, et la plus critique, était notre données globales de site . S'appuyant sur la structure de sous-répertoire 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 les fichiers individuels pour chaque entrée dans {{locale-code}}. 11tydata.js saisis par localisation, tous conçus pour être importés par nos scripts de navigateur. La lourde tâche 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. Il nous permet également de générer par programmation des pages basées sur nos localisations en bouclant sur site.l10n . Ceci, combiné à nos collections spécifiques à la localisation, utilisons la pagination de 11ty pour créer des pages d'accueil et des pages d'accueil localisées sans conserver de pages HTML séparées pour chacune.

Conclusion

Obtenir une internationalisation et une localisation correcte peut être difficile; Il est essentiel de comprendre comment les différentes stratégies et la complexité affectent les choses pour faciliter les choses. Choisissez une stratégie i18n qui convient naturellement aux sites statiques, aux sous-répertoires, puis créez des outils pour automatiser des parties de i18n et 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 répond non seulement à la taille de l'écran, mais également au contenu. En fin de compte, vous aurez un site que vos utilisateurs de tous les paramètres régionaux adoreront et qui peut être maintenu par les auteurs et les traducteurs comme s'il s'agissait d'un simple site à langue unique.

(ra, il) [19659103]

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)

Articles similaires