エンジニアリング//9 読了時間

Translation Automation:CI/CDとWebhooksでローカライゼーションを効率化する

Eray Gündoğmuş
共有

Translation Automation:CI/CDとWebhooksでローカライゼーションを効率化する

重要なポイント

  • Translation Automationは開発者と翻訳者の間のファイルの手動受け渡しを排除し、ローカライゼーションのサイクル時間を短縮します
  • CI/CDインテグレーションにより、新しい文字列が自動的に抽出、翻訳、マージされる継続的なローカライゼーションが可能になります
  • Webhooksにより、翻訳が完了したときにTMSプラットフォームがアクション(ビルド、通知、デプロイメント)をトリガーできます
  • 自動化により、未翻訳コンテンツや古い翻訳を出荷するリスクが軽減されます
  • 適切に自動化されたワークフローにより、ローカライゼーションのターンアラウンドを数週間から数時間に短縮できます

Auto Translationとは何ですか?

本質的に、auto translationとは翻訳ワークフローから手動ステップを取り除き、コンテンツが最小限の人間の介入でソース言語からターゲット言語に移行できるようにする実践です。この用語は幅広いスペクトルをカバーしています――Google TranslateへのシンプルなAPI呼び出しから、コードベース内の新しい文字列を検出し、コンテキストを考慮したAIで翻訳し、人間のレビューにルーティングし、承認された翻訳をプルリクエストとしてリポジトリにマージバックする完全にオーケストレーションされたパイプラインまで。

Automatic translationが重要な理由は、現代のソフトウェアチームが継続的にリリースするからです。翻訳プロセスが手動ファイルエクスポート、メール調整、手動インポートを必要とする場合、それはすべての国際リリースを遅らせるボトルネックになります。Auto Translationはそのボトルネックを解消します。

Automatic translationの成熟度には3つのレベルがあります:

  1. 基本的なauto translation:開発者がMT API(DeepL、Google Translate、Azure Translator)を呼び出してファイルを翻訳し、手動で出力を統合します。単発のタスクには速いですが、スケールしません。
  2. 半自動翻訳:TMSがリポジトリまたはCMSの変更を監視し、translation memoryとmachine translationを自動的に適用してから人間のレビュアーに通知します。パイプラインの大部分は介入なしで実行されますが、公開前に人間が承認します。
  3. 完全自動化された翻訳パイプライン:CI/CD統合ワークフローで、マージ時に文字列の変更が検出され、AIで翻訳され、quality gates(プレースホルダーチェック、長さ検証、完全性しきい値)で検証され、すべてのチェックが通過した場合に自動的にマージバックされます。人間のレビューは必要とするコンテンツタイプ(マーケティングコピー、法的テキスト)に予約されています。

このガイドの残りの部分はレベル2と3に焦点を当てています――automatic translationを一回限りのショートカットではなく、開発ワークフローの持続可能な部分にするCI/CDおよびwebhook駆動のアプローチです。

なぜ翻訳を自動化するのですか?

手動ローカライゼーションワークフローでは、開発者が翻訳ファイルを抽出し、翻訳者にメールで送るかTMSにアップロードし、翻訳を待ち、完成したファイルをダウンロードし、コードベースにマージバックします。各受け渡しにより遅延とエラーの機会が生まれます。

Translation Automationは、ソースコードリポジトリを翻訳管理システムに直接接続することでこれらの受け渡しを排除します。開発者が変更をコミットすると、新しいまたは変更された文字列が自動的に検出されて翻訳に送られます。翻訳者が作業を完了すると、翻訳が自動的に同期されます。

自動化されたローカライゼーションパイプライン

典型的な自動化パイプラインはこのフローに従います:

開発者がコードをコミット
        ↓
CI/CDが変更された翻訳ファイルを検出
        ↓
TMS CLIが新規/変更された文字列をTMSにプッシュ
        ↓
TMSがtranslation memoryを適用(即時マッチ)
        ↓
マッチしない文字列 → MTプリ翻訳または人間の割り当て
        ↓
翻訳者がTMSで翻訳を完了
        ↓
Webhookがトリガー:"translations completed"
        ↓
CI/CDが完成した翻訳をリポジトリに取得
        ↓
新しい翻訳を含むPRが作成される
        ↓
レビュー、マージ、デプロイ

CI/CD統合パターン

GitHub Actionsの例

ほとんどのTMSプラットフォームはCI/CDパイプラインで使用できるCLIツールを提供しています:

# .github/workflows/sync-translations.yml
name: Sync Translations

on:
  push:
    branches: [main]
    paths:
      - 'src/locales/en/**'

jobs:
  push-sources:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Push source strings to TMS
        run: |
          npx @better-i18n/cli push \
            --project your-org/your-project \
            --source src/locales/en
        env:
          BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}

スケジュールに従って翻訳を取得

# .github/workflows/pull-translations.yml
name: Pull Translations

on:
  schedule:
    - cron: '0 */6 * * *'  # 6時間ごと
  workflow_dispatch:       # 手動トリガー

jobs:
  pull-translations:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pull completed translations
        run: |
          npx @better-i18n/cli pull \
            --project your-org/your-project \
            --target src/locales
        env:
          BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}
      - name: Create PR if translations changed
        uses: peter-evans/create-pull-request@v6
        with:
          title: 'chore(i18n): update translations'
          commit-message: 'chore(i18n): pull latest translations from TMS'
          branch: i18n/update-translations

GitLab CI/CD

# .gitlab-ci.yml
push-sources:
  stage: sync
  only:
    changes:
      - src/locales/en/**
  script:
    - npx @better-i18n/cli push --project $PROJECT_ID --source src/locales/en

Webhook駆動のワークフロー

Webhooksにより、TMSはイベントが発生したときにシステムに通知できます――翻訳完了、レビュー承認、新しい文字列の検出など。

一般的なWebhookイベント

イベントトリガー典型的なアクション
translation.completed言語のすべての文字列が翻訳された翻訳を取得、PRを作成
translation.reviewed翻訳がレビューを通過ステージングにデプロイ
source.updated新しいソース文字列が検出された翻訳者に通知
project.exported翻訳エクスポートが準備完了ダウンロードしてマージ

Webhookハンドラーの例

// Express.js webhookハンドラー
app.post('/webhooks/translations', (req, res) => {
  const { event, language, project } = req.body;

  if (event === 'translation.completed') {
    // API経由でGitHub Actionsワークフローをトリガー
    triggerWorkflow('pull-translations', {
      language,
      project,
    });
  }

  res.status(200).json({ received: true });
});

ファイルフォーマットに関する考慮事項

異なるファイルフォーマットは自動化の動作に影響します:

フォーマット強みよく使われる環境
JSON(フラット/ネスト)解析が容易、広くサポートされているReact, Vue, Angular
XLIFF業界標準、メタデータを保持エンタープライズツール
PO/POT成熟したツール、翻訳者に優しいDjango, Rails, PHP
RESX.NETネイティブフォーマットC#、.NETプロジェクト
ARBFlutter/Dart標準Flutterアプリ
Strings/StringsdictiOSネイティブフォーマットiOS/macOSアプリ
XMLAndroidネイティブフォーマットAndroidアプリ

自動化パイプラインは、コードベースが使用する特定のフォーマットを処理する必要があります。ほとんどのTMS CLIツールはすべての一般的なフォーマットをサポートしています。

文字列抽出の自動化

別の翻訳ファイルを使用しないプロジェクトでは、自動化された文字列抽出がソースコード内の翻訳可能な文字列を識別します:

静的解析

ツールが翻訳関数呼び出しのソースコードをスキャンします:

// これらのパターンは抽出ツールによって検出されます:
t('home.title')
useTranslations('common')
formatMessage({ id: 'greeting' })

抽出設定

{
  "extract": {
    "patterns": ["src/**/*.{tsx,ts}"],
    "functions": ["t", "useTranslations", "formatMessage"],
    "output": "src/locales/en/messages.json"
  }
}

pre-commitフックまたはCIステップとして抽出コマンドを実行することで、新しい翻訳可能な文字列が常にキャプチャされることが保証されます。

自動化パイプラインのQuality Gates

自動化には、壊れた翻訳が本番に到達するのを防ぐための品質チェックが含まれている必要があります:

  1. プレースホルダー検証:ソース文字列のすべてのプレースホルダー({name}{count})が翻訳に存在することを確認
  2. 長さ検証:ソース文字列の長さを大幅に超える翻訳にフラグを立てる(UIオーバーフローを引き起こす可能性がある)
  3. 完全性チェック:デプロイメント前にすべての必要な言語が最低翻訳パーセンテージを満たすことを確認
  4. フォーマット検証:翻訳ファイルが有効なJSON/XLIFF/POであることを確認(構文エラーなし)
# CI内のQuality gate
- name: Validate translations
  run: |
    npx @better-i18n/cli validate \
      --source src/locales/en \
      --target src/locales \
      --min-coverage 95

よくある落とし穴

  1. 過剰な同期:すべてのコミットで翻訳を取得するとノイジーなPRが作成されます。代わりにスケジュールされたまたはwebhookトリガーの取得を使用してください。
  2. コンテキストの欠如:自動化された抽出は文字列をキャプチャしますが、スクリーンショットや説明はキャプチャしません。コメントまたはTMS機能を通じてコンテキストを提供してください。
  3. ブランチコンフリクト:翻訳PRはフィーチャーブランチとコンフリクトする可能性があります。コンフリクトを最小限に抑えるために翻訳の更新を頻繁にマージしてください。
  4. シークレット管理:TMS APIトークンはリポジトリにコミットせず、CI/CDシークレットに安全に保存する必要があります。
  5. Rate Limiting:TMSプラットフォームへのAPI呼び出しはレート制限される場合があります。自動化スクリプトにバックオフとリトライロジックを実装してください。

FAQ

どのくらいの頻度で翻訳を同期すべきですか?

main(またはプライマリブランチ)へのすべてのマージでソース文字列をプッシュしてください。翻訳はスケジュール(4-6時間ごと)または翻訳が完了したときのwebhookを介して取得してください。フィーチャーブランチへのすべてのコミットで同期することは避けてください――不必要なノイズが生まれます。

翻訳PRを自動マージすべきですか?

quality gates(プレースホルダー検証、フォーマットチェック)を持つ確立されたワークフローでは、翻訳PRの自動マージは安全かもしれません。新しいセットアップでは、品質チェックに自信が持てるまで手動レビューを要求してください。多くのチームは非クリティカルな言語では自動マージし、主要市場ではレビューを要求します。

翻訳がビルドを壊した場合はどうすればよいですか?

マージ前に翻訳ファイルを検証するCIチェックを追加してください。翻訳ファイルに無効な構文、欠落したプレースホルダー、その他の問題がある場合、PRはCIで失敗しマージされないようにすべきです。これにより壊れた翻訳が本番に到達するのを防ぎます。

Auto Translationは本番に十分ですか?

Auto Translation――つまり人間のレビューなしの完全に自動化されたmachine translation――は、スピードが磨きよりも重要な内部ツール、開発者向けドキュメント、低リスクコンテンツに適しています。ユーザー向けの製品UI、マーケティングコピー、法的コンテンツには、auto translationは人間のレビューを含むパイプラインの最初のドラフトとして機能すべきです。CI/CDコンテキストにおけるautomatic translationの目標は人間を排除することではなく、人間を遅らせる手動調整を排除することです。

Comments

Loading comments...