ある日、社長から「うちのサイト、多言語化しようぜ。ビルド時に自動で翻訳できる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) / マークアップエンジニア / フロントエンドエンジニア / ウェブディレクター