目次
ローカライゼーションのためのCI/CD:デプロイメントパイプラインで翻訳を自動化する
重要なポイント
- CI/CDインテグレーションにより、翻訳ファイルの手動管理が不要になり、すべてのデプロイメントで翻訳が確実にリリースされます
- 自動化されたstring抽出と検証により、翻訳の欠落が本番環境に到達する前に検出されます
- Webhookによって起動されるビルドにより、継続的なローカライゼーションが可能になります——翻訳は承認されるとすぐに公開されます
- マージ前のチェックにより、未翻訳のstringを含むPRをブロックし、不完全なローカライゼーションのリリースを防止できます
CI/CDでローカライゼーションを自動化する理由
手動のローカライゼーションワークフローはボトルネックを生み出します:
- 開発者がTMSへの新しいstringのアップロードを忘れる
- 翻訳済みファイルがTMSで誰かがダウンロードするのを待っている
- ファイルの手動配置によりマージコンフリクトが発生する
- 欠落した翻訳が本番環境に紛れ込む
CI/CD自動化は、翻訳の同期をすべてのビルドとデプロイメントの標準的な一部にすることで、これらの問題を解決します。
パイプラインアーキテクチャ
Code Push → CI Triggered → Extract Strings → Push to TMS
↓
Production ← Deploy ← Build ← Pull Translations ← Translations Complete (webhook)
GitHub Actionsでの実装
プルリクエスト時:翻訳を検証する
name: Translation Check
on: pull_request
jobs:
check-translations:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Scan for new strings
run: npx better-i18n scan --check
# 未翻訳のstringが見つかった場合に失敗します
- name: Validate translation files
run: npx better-i18n validate
# JSONシンタックス、欠落キー、プレースホルダーの整合性をチェックします
Mainへのマージ時:同期してデプロイする
name: Deploy with Translations
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Push new strings to TMS
run: npx better-i18n push
env:
BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}
- name: Pull latest translations
run: npx better-i18n pull --all
- name: Build
run: npm run build
- name: Deploy
run: npm run deploy
翻訳完了時:Webhookによるビルドの起動
name: Translation Update
on:
repository_dispatch:
types: [translations-updated]
jobs:
rebuild:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npx better-i18n pull --all
- run: npm run build
- run: npm run deploy
自動検証チェック
これらのチェックをCI Pipelineに組み込んでください:
| チェック | 検出内容 | 実行タイミング |
|---|---|---|
| 翻訳の欠落 | ターゲットロケールに翻訳がないキー | PRチェック |
| プレースホルダーの整合性 | ソースでは{name}だが翻訳では{nom}が使用されている | PRチェック |
| JSON/XLIFFシンタックス | 不正な形式の翻訳ファイル | 毎ビルド |
| string長 | UIの文字数制限を超える翻訳 | PRチェック |
| 未使用キー | コードで参照されなくなった翻訳キー | 週次スケジュール |
不完全な翻訳の処理
デプロイメント時にすべての翻訳が完成しているとは限りません。対策として:
- ソース言語へのフォールバック — 翻訳がない場合は英語を表示する(最も一般的)
- デプロイメントのブロック — すべてのターゲットロケールが100%翻訳された場合のみデプロイする(最も厳格)
- パーセンテージ閾値 — ロケールが90%以上翻訳されていればデプロイし、それ以下の場合はブロックする
- キーレベルの優先度 — 重要なUI stringは必ず翻訳し、非重要なものはフォールバック可能にする
FAQ
翻訳ファイルをgitにコミットすべきですか? はい。翻訳ファイルをコミットすることで、TMS APIが利用できない場合でもビルドが機能します。CI Pipelineは最新の翻訳を取得し、変更を自動的にコミットします。
翻訳ファイルのマージコンフリクトを防ぐには? TMSを単一の真実のソースとして使用してください。CIはビルドのたびに翻訳を最新の状態で取得し、ローカルファイルを上書きします。開発者は翻訳ファイルを手動で編集することはありません。
デプロイが必要なときに翻訳が準備できていない場合は? フォールバック戦略を使用してください(未翻訳のstringにはソース言語を表示)。翻訳完了率を追跡し、閾値を下回った場合はアラートを設定してください。
ブランチベースの開発はどのように管理しますか? feature branchのstringを別個のTMSネームスペースまたはブランチにプッシュしてください。feature branchがmainにマージされるときに翻訳をマージします。
モバイルアプリにもローカライゼーションCI/CDを実行できますか? はい。同じ原則が適用されます——stringをTMSにプッシュし、ビルド中に翻訳をプルし、リリース前に検証します。モバイル特有の考慮事項:ASOメタデータをパイプラインに含め、.strings/.xmlファイル形式を検証してください。