使用 Google 翻譯 API 將 Astro SSG 網站多語言化

某天，董事長說：「我們的網站也來多語言化吧。聽說有個叫 Google Cloud Translation API 的東西，可以在建置時自動翻譯！」於是就收到了這個指示。

本公司網站採用 Astro 構建的靜態網站（SSG）。我們決定研究 Google Cloud Translation API 並進行實裝。

事前準備：啟用 API 金鑰並建立服務帳戶

啟用 Cloud Translation API

從 Google Cloud Console 的「API 與服務」選擇「Cloud Translation API」來啟用。

建立服務帳戶與金鑰

為了使用 API，我們需要建立服務帳戶並下載 JSON 金鑰。

這個 JSON 金鑰包含私密金鑰，務必絕對不要公開。

為服務帳戶授予存取權限

前往 IAM，將服務帳戶的電子郵件地址新增至主體，並將角色設定為「Cloud Translation API 使用者」。

如何生成多語言頁面

最初嘗試的方法是「複製 Astro 檔案，在當下呼叫翻譯 API，自動產生多語言的 Astro 檔案」。

雖然頁面能夠產生，但卻遇到了各式各樣的問題：代碼區塊(code fence)部分損壞、import 的元件無法對應、屬性內書寫標籤時無法正常運作等等。由於這些問題無法順利解決，所以決定改變策略。

最後我們採用了一個簡單的 postbuild 流程，「針對建置後生成的靜態 HTML 進行翻譯處理」。

語言設定與 Astro 的 i18n 設定檔同步

為了管理網站的多語言結構，我們將原有的 Astro i18n 設定檔（LOCALES_SETTING）作為翻譯指令碼的「設定檔」來使用。

想要新增語言時，只需在這裡新增即可。

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',
  },
};

語言切換的實作

語言選擇下拉菜單也是從剛才的 i18n 設定檔產生的。label 是選項名稱，所以我不想翻譯它。因此，我新增了用 label 的值進行覆蓋的處理。（translate="no" 在 Cloud Translation API 中似乎沒有作用）

順帶一提，我曾被要求「在下拉選單中加入國旗」，並嘗試實現，但看來在語言切換時加入國旗是一種反模式。例如，如果德語使用者是奧地利使用者，看到德國國旗可能會感到困惑，這表示國家和語言不一定相符。你一提才明白，確實如此。在某些情況下，這可能會成為敏感問題。

透過快取減少 API 使用

至此為止，多語言生成的機制已基本完成。但問題在於成本。

在不斷試錯和多次構建的過程中，API 的使用費用轉眼就超過了 10,000日圓。

於是，我在構建時將 API 處理過的日文和翻譯的組合作為快取，保存到名為 translate-cache.json 的檔案中。下次構建時從該 JSON 中套用，只對缺少的項目進行 API 調用，並將結果追加到 JSON 中。

快取會以這樣的方式保存。

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

藉此大幅壓縮成本！根據更新頻率而定，日常運營成本每月僅需數百日圓。

營運上的注意事項

當在 CMS 中新增文章並透過部署 webhook 進行構建時，伺服器只能參照 Git 上的舊快取檔案。因此，我們確立了一個營運規則：新增內容時在本機進行構建，並將更新的快取檔案推送到 Git。

控制不正確的翻譯

果然是機器翻譯。有些地方出現了奇怪的翻譯。
公司名稱「Liberogic」出現了「Liberlogic」或「Libelogic」等不一致的情況，以及法人格標記（Inc.、Ltd. 等）沒有統一等問題，專有名詞的表記不一致相當明顯。

Cloud Translation API 有字彙表功能，但那只是輔助機器翻譯，無法進行完全細致的控制。除了上傳 CSV 檔案外，每次都需要執行命令來重新建立資源，這對不太熟悉網頁的營運人員來說很困難。

透過試算表整合進行確實的控制

因此，我們將語言和正確性整理在試算表中，在建置時以 CSV 格式取得該試算表，透過文本替換處理，就能夠以正確的表記進行覆蓋修正。

這樣一來，營運人員只需更新試算表，即可在不觸碰程式碼的情況下，對翻譯進行一定程度的控制。

總結

Google Cloud Translation API 的自動翻譯經過多次嘗試，最終打造出了比預期更實用的機制。作為成本低廉的輕量級多語言化方案，我認為已經相當足夠！

（社長說還想支援 RTL 的阿拉伯語，但那將是一項大工程呀）