Topics

Astro SSGサイトをGoogle翻訳APIで多言語化してみた

  • column

ある日、社長から「うちのサイト、多言語化しようぜ。ビルド時に自動で翻訳できる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してるコンポーネントは対応できなかったり、属性内にタグを書いている場合にうまくいかなかったりなど、どうにもうまくいかない箇所がでてきたので方針転換。

結局「ビルド後の生成された静的HTMLに対して翻訳処理を行う」というシンプルなpostbuild処理にしました。

言語設定はAstroのi18n設定ファイルと連動

サイトの多言語構造を管理するため、もともと持っていたAstroのi18n設定ファイル(LOCALES_SETTING)を翻訳スクリプトの「設定ファイル」として利用しました。

言語を追加したい時は、ここに追記するだけでOK。

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で記事を追加し、デプロイフックでビルドする場合、サーバーはGit上にある古いキャッシュファイルしか参照できません。そのため、コンテンツを追加した際はローカルでビルドを行い、更新されたキャッシュファイルをGitにプッシュするという運用ルールを徹底することにしました。

おかしい翻訳を制御する

やはり機械翻訳。ところどころおかしな翻訳が出てきます。
自社名「Liberogic」が「Liberlogic」や「Libelogic」とブレてしまったり法人格の表記(Inc.、Ltd. など)が統一されなかったりなど、固有名詞で表記揺れが目立ちました。

Cloud Translation APIには用語集機能があるのですが、あくまで機械翻訳をアシストするもので完全な細かい制御はできないのと、CSVをアップロードするだけでなく、毎回コマンドを実行してリソースを再作成する必要があり、ウェブに詳しくない運用担当者には難しい。

スプレッドシート連携による確実な制御

そこで、スプレッドシートに言語と正誤をまとめ、ビルド時にこのスプレッドシートをCSV形式で取得し、テキスト置換処理をすることで、正しい表記に上書き修正できるようにしました。

これにより、運用担当者はスプレッドシートを更新するだけで、コードを触ることなく翻訳をある程度制御できるようになりますね。

まとめ

Google Cloud Translation APIの自動翻訳、試行錯誤したものの思ったよりも実用的な仕組みにできました。費用を抑えてお手軽簡易多言語化としては十分に思います!

(社長はRTLのアラビア語も対応したいって言ってるけど、これは大工事になるなぁ)

この記事を書いた人

DTPからWebの世界へ飛び込み、気づけばマークアップもフロントエンドもディレクションもアクセシビリティもこなす"技の仙人"。リベロジック創業期からマルチに活躍し、今や社内の生き字引的存在。最近は「アクセシビリティ対応、もっとAIに頼れないかな?」と、プロンプトを駆使した効率化の探究にハマり中。技術も思考も、まだまだ進化中

フタさん

IAAP認定ウェブアクセシビリティスペシャリスト(WAS) / マークアップエンジニア / フロントエンドエンジニア / ウェブディレクター

このスタッフの記事を見る

安心のチーム体制とスピードのある対応力が自慢

リベロジックでは、ベテランスタッフが積極的にプロジェクトを推進するため、お客様から高く評価されています。
プロジェクトマネージャー、ディレクターをきちんとアサインし、プロジェクト全体をスムーズに進行することを心掛けています。 不必要なフルコミットでのコスト増加を防ぎ、適材適所にリソースを配分するスタイルで、業務内容の把握から見積作成/提出の速さにも定評があります。

当社はSES的な常駐業務等は積極的に行っておりませんので予めご了承ください。

Slack、Teams、Redmine、Backlog、Asana、Jira、Notion、Google Workspace、Zoom、Webexなど、ほぼすべての主要なプロジェクト管理ツールやチャットツールをご利用いただけます。

SESやオフショアを利用する大規模案件において、技術的な課題や取り組み方にお悩みはございませんか?

ケーススタディ