Un jour, le président m'a donné l'ordre : « Rendons notre site web multilingue. Apparemment, il existe une API Google Cloud Translation qui peut traduire automatiquement pendant le processus de création ! »
Notre site web est un site statique (SSG) construit avec Astro. J'ai décidé de tenter de l'implémenter tout en effectuant des recherches sur l'API Google Cloud Translation.
Prérequis : activer une clé API et créer un compte de service
Activation de l'API de traduction dans le cloud
Console Google CloudAccédez à « API et services » et sélectionnez « API de traduction cloud ».Activer
Création d'un compte de service et d'une clé
Pour utiliser l'API, créez un compte de service et téléchargez une clé JSON.
Cette clé JSON contient votre clé privée et ne doit jamais être rendue publique.
Autorisation d'accès au compte de service
Accédez à IAM et ajoutez l'adresse e-mail du compte de service en tant que principal et le rôle en tant qu'« Utilisateur de l'API de traduction cloud ».
Comment générer des pages multilingues
La première méthode que j'ai essayée consistait à « copier le fichier Astro, appeler l'API de traduction sur place et générer automatiquement des fichiers Astro multilingues ».
Bien que la page ait été générée, nous avons rencontré plusieurs problèmes, tels que des barrières de code brisées, une incompatibilité avec les composants importés et des problèmes lorsque des balises étaient écrites dans des attributs, nous avons donc changé d'approche.
Finalement, j'ai opté pour un processus de post-compilation simple qui effectue la traduction du HTML statique généré après la compilation.
Les paramètres de langue sont liés au fichier de configuration i18n d'Astro.
Pour gérer la structure multilingue du site, j'ai utilisé le fichier de configuration Astro i18n d'origine (LOCALES_SETTING) a été utilisé comme « fichier de configuration » pour le script de traduction.
Pour ajouter une langue, il suffit de l'ajouter ici.
export const LOCALES_SETTING: LocaleSetting = {
ja: {
label: '日本語',
lang: 'ja',
oglocale: 'ja_JP',
path: 'ja',
},
en: {
label: 'English',
lang: 'en',
oglocale: 'en_US',
path: 'en',
},
de: {
label: 'Deutsch',
lang: 'de',
oglocale: 'de_DE',
path: 'de',
},
es: {
label: 'Español',
lang: 'es',
oglocale: 'es_ES',
path: 'es',
},
cn: {
label: '简体中文',
lang: 'zh-CN',
oglocale: 'zh_CN',
path: 'zh-cn',
},
tw: {
label: '繁體中文',
lang: 'zh-TW',
oglocale: 'zh_TW',
path: 'zh-tw',
},
};
implémentation du changement de langue
Le menu déroulant de sélection de la langue est également généré à partir du fichier de configuration i18n mentionné précédemment. Comme l'étiquette correspond au nom de l'élément sélectionné, nous ne souhaitons pas la traduire. Par conséquent, nous avons ajouté du code pour la remplacer par la valeur de l'étiquette. (Il semble que `translate="no"` ne fonctionne pas avec l'API Cloud Translation.)
Au fait, on m'a demandé d'« ajouter les drapeaux nationaux au menu déroulant », alors j'ai essayé, mais il semble que ce soit une mauvaise pratique. Par exemple, si un utilisateur germanophone est autrichien, il pourrait être perturbé par le drapeau allemand. Les pays et les langues ne correspondent donc pas forcément. Maintenant que vous le dites, c'est vrai. Cela pourrait poser problème dans certains cas.
Mise en cache pour minimiser l'utilisation de l'API.
À ce stade, le système de génération de plusieurs langues est presque achevé, mais le problème réside dans le coût.
Au fil de mes essais et de mes nombreuses tentatives de compilation, les frais d'utilisation de l'API ont rapidement dépassé les 10 000 yens.
Par conséquent, lors du processus de compilation, la combinaison du japonais et de la traduction traitée par l'API est utilisée comme cache.translate-cache.jsonLes données seront enregistrées dans un fichier, et la prochaine compilation utilisera ce JSON. La spécification a été modifiée afin que seules les données manquantes soient récupérées via l'API, et que les résultats soient ajoutés au JSON.
Il sera enregistré comme ceci.
{
"en:UIデザイン": "UI Design",
"en:私たちについて": "About Us",
"en:サービス": "Service",
...
}
Cela réduit considérablement les coûts ! Selon la fréquence des mises à jour, les frais de fonctionnement ne seront que de quelques centaines de yens par mois.
Notes opérationnelles
Lors de l'ajout d'articles via un CMS et la compilation par déploiement, le serveur n'a accès qu'aux anciens fichiers de cache sur Git. Par conséquent, nous avons décidé d'imposer une règle stricte : la compilation locale est effectuée à chaque ajout de contenu, et les fichiers de cache mis à jour sont ensuite transférés vers Git.
Contrôler les traductions incorrectes
Après tout, c'est une traduction automatique, et il y a quelques traductions étranges ici et là.
On constatait des incohérences notables dans l'orthographe des noms propres, comme le nom de la société « Liberogic » parfois écrit « Liberogic » ou « Liberogic », et la notation du statut juridique des entreprises (Inc., Ltd., etc.) n'étant pas normalisée.
L'API de traduction dans le cloud propose un glossaire, mais celui-ci ne fait qu'assister la traduction automatique et n'offre pas un contrôle complet et précis. De plus, elle nécessite non seulement le chargement d'un fichier CSV, mais aussi l'exécution de commandes pour recréer les ressources à chaque fois, ce qui représente une difficulté pour le personnel d'exploitation peu familier avec le web.
Contrôle fiable grâce à l'intégration de feuilles de calcul
Nous avons donc compilé la langue et les informations correctes/incorrectes dans une feuille de calcul, récupéré cette feuille de calcul au format CSV lors du processus de compilation, et effectué un remplacement de texte pour écraser et corriger la notation.
Cela permet au personnel d'exploitation d'avoir un certain contrôle sur les traductions en mettant simplement à jour une feuille de calcul, sans toucher au code.
résumé
Après quelques essais, j'ai réussi à créer un système de traduction automatique plus pratique que prévu grâce à l'API Google Cloud Translation. Pour une prise en charge multilingue simple et économique, je le trouve parfaitement adapté !
(Le président affirme vouloir ajouter la prise en charge de la langue arabe à RTL, mais il s'agira d'un projet d'envergure.)
Il est passé de la PAO au web et est rapidement devenu un expert dans son domaine, maîtrisant le balisage, la conception d'interfaces, la direction artistique et l'accessibilité. Actif dans divers secteurs depuis la création de Liberogic, il est aujourd'hui une véritable encyclopédie vivante au sein de l'entreprise. Récemment, il s'est passionné pour l'amélioration de l'efficacité grâce aux invites, se demandant : « Peut-on davantage s'appuyer sur l'IA pour l'accessibilité ? » Ses technologies et sa réflexion sont en constante évolution.
Futa
Spécialiste certifié en accessibilité web (WAS) IAAP / Ingénieur en balisage / Ingénieur front-end / Directeur web