Internationalisation d'un site Astro SSG avec l'API Google Translate

Un jour, le PDG nous a donné l'ordre : « Rendons notre site multilingue. Apparemment, il existe une API Google Cloud Translation qui peut traduire automatiquement à la compilation ! »

Notre site est construit avec Astro en tant que site statique (SSG). Nous avons décidé d'explorer l'API Google Cloud Translation et de l'implémenter.

Préparation préalable : activation de la clé API et création d'un compte de service

Activation de l'API Cloud Translation

Activez l'API Cloud Translation depuis « APIs et services » dans la Google Cloud Console.

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 la clé JSON.

Cette clé JSON contient une clé privée ; soyez extrêmement prudent et ne la publiez jamais.

Accordez les droits d'accès au compte de service

Accédez à IAM, ajoutez l'adresse e-mail du compte de service au principal, et définissez le rôle sur « Utilisateur de l'API Cloud Translation ».

Comment générer des pages multilingues

La première approche que j'ai essayée consistait à « copier les fichiers Astro, exécuter l'API de traduction sur place, et générer automatiquement des fichiers Astro multilingues ».

Les pages ont pu être générées, mais nous avons rencontré des problèmes : les sections de code se sont cassées, les composants importés n'étaient pas gérés, et cela ne fonctionnait pas lorsque des balises étaient écrites à l'intérieur d'attributs. Nous avons donc changé d'approche.

En fin de compte, nous avons opté pour un simple postbuild : « appliquer le traitement de traduction au HTML statique généré après la compilation ».

Les paramètres de langue sont synchronisés avec le fichier de configuration i18n d'Astro

Pour gérer la structure multilingue du site, nous avons réutilisé le fichier de configuration i18n d'Astro existant (LOCALES_SETTING) comme « fichier de configuration » du script de traduction.

Pour ajouter une langue, il suffit de l'ajouter à ce fichier.

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 langue est également généré à partir du fichier de configuration i18n mentionné précédemment. Puisque le label devient le nom de l'élément sélectionné, je ne veux pas le traduire. J'ai donc ajouté un traitement pour l'écraser avec la valeur du label. (Il s'avère que translate="no" ne fonctionne pas avec l'API Cloud Translation)

En passant, on m'a suggéré d'ajouter des drapeaux dans la liste déroulante de sélection de langue, et j'ai tenté de le faire. Mais il s'avère que c'est un anti-motif pour les sélecteurs de langue. Par exemple, un locuteur allemand qui est utilisateur en Autriche pourrait être confus en voyant le drapeau allemand — les pays et les langues ne correspondent pas nécessairement. Maintenant que j'y pense, c'est effectivement vrai. Dans certains cas, cela pourrait même devenir un problème sensible.

Mise en cache pour minimiser l'utilisation de l'API

À ce stade, le mécanisme de génération multilingue était presque terminé. Cependant, le problème était le coût.

Après plusieurs itérations et constructions répétées, les frais d'utilisation de l'API ont rapidement dépassé les 10 000 ¥.

J'ai donc décidé de sauvegarder les paires japonais-traduction traitées par l'API dans un fichier appelé translate-cache.json au moment de la construction. Lors de la prochaine construction, l'application applique les données à partir de ce JSON. Seules les traductions manquantes sont obtenues via l'API, et les résultats sont ajoutés au JSON.

Voici à quoi ressemble la sauvegarde.

{
  "en:UIデザイン": "UI Design",
  "en:私たちについて": "About Us",
  "en:サービス": "Service",
  ...
}

Cela a permis de réduire considérablement les coûts ! Selon la fréquence de mise à jour, les coûts d'exploitation restent de quelques centaines de yen par mois.

Points importants pour l'exploitation

Lorsque j'ajoute des articles dans le CMS et déclenche une construction via un webhook de déploiement, le serveur ne peut référencer que l'ancien fichier de cache présent dans Git. Par conséquent, j'ai établi une règle d'exploitation : à chaque ajout de contenu, j'effectue une construction en local, puis je pousse le fichier de cache mis à jour vers Git.

Contrôler les traductions incorrectes

C'est bel et bien de la traduction automatique. On retrouve çà et là des traductions étranges.
Le nom de notre entreprise « Liberogic » a varié en « Liberlogic » ou « Libelogic », et les mentions de statut juridique (Inc., Ltd., etc.) n'étaient pas cohérentes, ce qui a créé des incohérences flagrantes dans les noms propres.

Cloud Translation API dispose d'une fonction de glossaire, mais elle ne sert qu'à assister la traduction automatique et ne permet pas un contrôle précis et complet. De plus, au-delà du simple téléchargement d'un CSV, il faut exécuter une commande à chaque fois pour recréer les ressources, ce qui s'avère difficile pour les responsables d'exploitation qui ne sont pas versés en technologie web.

Un contrôle fiable grâce à l'intégration Google Sheets

Nous avons alors compilé les langues et les corrections dans une feuille Google Sheets, et lors de la génération, nous récupérons cette feuille au format CSV et effectuons un traitement de remplacement de texte pour corriger les formulations en remplaçant les mauvaises versions par les bonnes.

Grâce à cela, les responsables d'exploitation peuvent désormais contrôler la traduction dans une certaine mesure en mettant simplement à jour la feuille Google Sheets, sans avoir à toucher au code.

Conclusion

La traduction automatique via Google Cloud Translation API s'est avérée, après bien des essais et erreurs, beaucoup plus pratique que prévu. Pour une approche simple et économique de la multilingue, je pense que c'est tout à fait suffisant !

(Le PDG veut aussi supporter l'arabe RTL, mais ça va être un gros chantier...)