將 Astro SSG 網站透過 Google 翻譯 API 實現多語言化

某天，社長指示：「我們的網站來做多語言化吧。聽說有個叫 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 檔案」。

雖然頁面可以生成，但程式碼區塊會被破壞，無法處理 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 新增文章並透過部署 Hook 進行建置，伺服器只能參照 Git 上舊的快取檔案。因此，我們決定徹底執行一項營運規則：新增內容時先在本機建置，再將更新後的快取檔案推送至 Git。

控制奇怪的翻譯

果然還是機器翻譯，部分地方會出現奇怪的譯文。
公司名稱「Liberogic」被寫成「Liberlogic」或「Libelogic」，公司法人形式的寫法（Inc.、Ltd. 等）也未統一，專有名詞的寫法不一致的情況相當明顯。

Cloud Translation API 雖然有術語表功能，但它只是協助機器翻譯，無法完全精細控制；而且不只要上傳 CSV，每次還必須執行指令重新建立資源，對不熟悉網站的營運人員來說很困難。

透過試算表串接實現可靠的控制

因此，我們將語言與正誤整理在試算表中，建置時以 CSV 格式取得此試算表並執行文字取代處理，如此就能以正確的寫法覆寫修正。

如此一來，營運人員只要更新試算表，無需碰觸程式碼，就能在一定程度上控制翻譯結果，對吧？

總結

Google Cloud Translation API 的自動翻譯經過反覆嘗試，做出的機制比預期更實用。成本低、能輕鬆簡易地實現多語言化，我認為已經相當足夠！

（社長說也想支援 RTL 的阿拉伯語，但這會是大工程呢）