継続的ローカライゼーション：翻訳をコードベースと同期し続ける方法

継続的ローカライゼーション：翻訳をコードベースと同期し続ける方法

TL;DR / 主なポイント

• 継続的ローカライゼーションは、翻訳をリリース時の一回限りのタスクではなく、継続的なパイプラインのステップとして扱います — CI/CDがテストやデプロイを扱うのと同じ方法です。
• バッチ翻訳ワークフローは崩壊しますリリースペースが加速するにつれて：文字列が陳腐化し、マージコンフリクトが蓄積し、翻訳者がコンテキストを失います。
• 機能する継続的ローカライゼーションパイプラインには6つのステージがあります：コード変更、文字列抽出、翻訳トリガー、レビュー、マージ、デプロイ。各ステージは様々な程度に自動化できます。
• 主要な統合パターンは同期をトリガーする方法が異なります：VCSからのwebhook、CIステップでのCLIベースのpush/pullコマンド、ローカル開発向けのファイルウォッチャー、デプロイ不要の更新のためのOTA/CDN配信。
• この問題のすべての部分を解決する単一のツールはありません。適切なセットアップは、リリースペース、言語数、翻訳者のワークフロー、そしてOTAアップデートがプロダクトにとって重要かどうかによって異なります。

継続的ローカライゼーションとは何か？

継続的ローカライゼーションとは、翻訳をリリースサイクルごとに一度発生する手動ステップではなく、継続的で自動化されたプロセスとしてソフトウェア開発ライフサイクルに統合する実践です。

なぜそれが重要かを理解するために、従来のアプローチとの対比を考えてみましょう — しばしばバッチ翻訳またはウォーターフォール翻訳と呼ばれます。バッチワークフローでは、開発者が機能を完成させ、プロダクトマネージャーがすべての新しい文字列をスプレッドシートやエクスポートに収集し、ローカライゼーションマネージャーがそれらを翻訳者（社内または外部）に提出し、翻訳が数日または数週間後に戻ってきて、開発者がそれらをインポートし、リリースは最後のロケールの完了を待ちます。このサイクルは、ソフトウェアが四半期ごとに出荷されていた時代にはそれなりに機能しました。チームが週次または日次で出荷する場合には崩壊します。

CI/CDとの類比は直接的です。継続的インテグレーションが登場する前、開発者は長期のブランチで作業し、インテグレーションは遅く発生し、マージコンフリクトのコストは時間とともに増大しました。CIはインテグレーションをより早く、より頻繁に行うことで、そのコストを劇的に削減しました。継続的ローカライゼーションは翻訳に対して同じことをします：スプリント中に文字列の変更を蓄積してリリース時に調整するのではなく、各コード変更が即座に翻訳パイプラインをトリガーします。

このフレーミングはしばしばシフトレフトローカライゼーションと呼ばれます — テストに適用される「シフトレフト」と同じ概念で、問題を早期に発見する方が後で発見するよりもコストが低いというものです。書かれた当日に翻訳パイプラインに入る文字列は、完全なコンテキスト、バックログのプレッシャーなし、リリースをブロックするリスクなしに翻訳されます。リリース前日にパイプラインに入る文字列は、プレッシャー下で、しばしばコンテキストなしで、しばしば他の400の文字列と一緒にバッチで翻訳され、しばしば最初から間違っています。

継続的ローカライゼーションは、すべての文字列が数時間以内に翻訳されて出荷されることを意味しません。機械翻訳はその速度のギャップを埋めることができ、人間のレビューが後に続きます。構造的に意味することは、パイプラインが常に実行されているということです：新しい文字列が自動的に流れ込み、翻訳者のキューがインクリメンタルに更新され、翻訳が各ハンドオフを人間が調整することなくコードベースまたは配信レイヤーに流れ戻ります。

バッチ翻訳が崩壊する理由

バッチ翻訳は本質的に間違っているわけではありません — 出荷頻度が低いプロジェクトや少数の文字列を管理するプロジェクトでは、合理的なアプローチです。しかし、CI/CDパイプライン上のエンジニアリングチームにとって、バッチワークフローは4つの具体的な障害モードを生み出します。

リリース遅延。 翻訳が出荷の前提条件であり、翻訳がフィーチャーフリーズ後にトリガーされるバッチタスクである場合、リリースタイムラインは翻訳者のスループットによって制約されます。継続的に出荷するチームは、5営業日かかるローカライゼーションステップを受け入れることができません。リリースは翻訳された文字列なしで出荷するか（ソース言語、多くの場合英語をデフォルトとして）、または待つかのどちらかです — どちらも大規模には受け入れられません。

翻訳の陳腐化。 バッチモデルでは、文字列はすでに先に進んでいるコードベースからエクスポートされることが多いです。翻訳が届く頃には、文字列自体が変わっているかもしれません — ボタンラベルが言い換えられ、画面が再設計され、機能が削除されました。翻訳者は古いスナップショットから作業します。結果は、ライブプロダクトと一致しない翻訳、または破棄してやり直さなければならない翻訳作業です。

翻訳ファイルのマージコンフリクト。 複数の開発者が並行して作業していて、翻訳ファイルがリポジトリに存在する場合（JSON、YAML、XLIFF、または類似のもの）、それらのファイルへの同時変更はマージコンフリクトを生み出します。アプリケーションロジックのコンフリクトとは異なり、翻訳ファイルのコンフリクトは解決するのが面倒でエラーが発生しやすいです：2つのブランチが両方とも新しいキーを追加し、両方ともキーを削除し、両方ともキーを異なるものにリネームしました。バッチが大きいほど、コンフリクトは悪化します。

開発者と翻訳者の摩擦。 バッチワークフローでは、開発者と翻訳者の間のハンドオフは、時間的プレッシャー下で崩壊する慣習に依存する手動の、しばしば非同期のプロセスです。開発者はエクスポートを忘れます。翻訳者はコンテキストなしでファイルを渡されます。エクスポートとインポートの間でキーがリネームされます。インポートが翻訳者が直接加えた変更を上書きします。これらの障害はそれぞれ個別には致命的ではありません — しかし複合します。時間とともに、摩擦はチームがローカライゼーション品質を優先しなくなり、ローカライゼーション負債が技術的負債と同じように蓄積します。

継続的ローカライゼーションパイプライン

継続的ローカライゼーションパイプラインは、文字列の変更を6つのステージを通じて移動させます。パイプラインは人間の決定ではなく、コード変更によってトリガーされます。各ステージは、次のステージが手動介入なしに消費できる決定論的な出力を生成します。

コード変更
    |
    v
文字列抽出
    |
    v
翻訳トリガー
    |
    v
翻訳（MT + 人間によるレビュー）
    |
    v
リポジトリへのマージバック（またはCDNへのプッシュ）
    |
    v
デプロイ（またはCDNベースの場合はOTAアップデート）

ステージ1：コード変更。 開発者がコードベースに翻訳可能な文字列を追加、変更、または削除します。適切なi18nセットアップでは、これはキーバリューファイル（JSON、YAML、XLIFF）を更新するか、ランタイムで解決するコード内のキー参照を追加することを意味します。

ステージ2：文字列抽出。 パイプラインは、現在の状態を前回の抽出スナップショットと比較することによって、どの文字列が新しい、変更された、または削除されたかを識別します。これは通常、ローカライゼーションツールのCLIまたはCIスクリプトによって処理されます。出力は文字列変更の差分です — すべての文字列の完全エクスポートではなく、デルタのみです。実行のたびに差分ではなく完全エクスポートを計算するツールは、不必要な翻訳者の作業を生み出し、新しい文字列を優先することを難しくします。

ステージ3：翻訳トリガー。 新しいおよび変更された文字列が翻訳管理システム（TMS）に送られます。これはwebhook（VCSイベントがTMSへのAPIコールをトリガー）、CIステップ（CLIコマンドが成功したビルド後に文字列差分をプッシュ）、またはファイルウォッチャー（開発時に、ローカルエージェントがファイルの変更を監視して継続的に同期）を介して発生することができます。トリガーは自動である必要があります — このステップを開始するために人間を必要とすることはバッチ問題を再導入します。

ステージ4：翻訳。 翻訳者（人間または機械、またはその組み合わせ）がTMS内の新しい文字列を作業します。うまく設計されたシステムは、翻訳者がやり取りなしに正確な翻訳を生成するのを助けるために、スクリーンショット、コンポーネントコンテキスト、文字数制限、および隣接する文字列を提供します。機械翻訳は最初の下書きを自動的に生成できます；人間のレビュアーは正確さ、ブランドボイス、およびコンテキストに依存した修正に集中します。

ステージ5：マージ。 完成した翻訳は、ガバナンスモデルに応じて、プルリクエストとしてリポジトリにプッシュされるか、翻訳ブランチに直接コミットされます。OTA対応プラットフォームでは、このステップは翻訳された文字列をCDNまたはAPIエンドポイントにプッシュします — 配信パスのためにリポジトリを完全にバイパスします。

ステージ6：デプロイ。 ファイルベースの配信では、翻訳は次のビルドにバンドルされ、アプリケーションとともにデプロイされます。CDNベースの配信では、翻訳はすでにエッジでライブです — アプリケーションは新しいデプロイなしに次のリクエストでそれらを取得します。

重要な設計原則は、ステージ2から5が機械翻訳コンテンツに対して完全に自動化されるべきであり、人間のレビューは品質を向上させるが配信をブロックしないオプションのレイヤーとしてあるべきということです。人間のレビューは非同期であるべきです：MT翻訳を最初にフォールバックとして公開し、準備ができたときにレビューされた翻訳で置き換えます — 人間のレビューで公開をブロックしないでください、しかしすべてのコンテンツに対してMTを最終的なものとして扱わないでください。

統合パターン

コードベースを翻訳パイプラインに接続する方法によって、上記のどれだけが実際に自動化できるかが決まります。4つの主要な統合パターンがあり、それぞれ異なるトレードオフがあります。

VCS webhook。 リポジトリホスティングプラットフォーム（GitHub、GitLab、Bitbucket）は、コミットまたはプルリクエストが作成されたときにTMSにHTTPイベントを送信します。TMSはペイロードを解析し、どのファイルが変更されたかを識別し、新しい文字列を抽出し、翻訳のためにキューに入れます。これはCIパイプラインへの変更を必要とせず、ブランチがmainにマージされる前でも機能します。制限は、TMSがあなたのファイル形式とプロジェクト構造を理解する必要があることです — 設定はコードベースではなくTMS側で行われます。

CIステップ（CLI）。 CIパイプラインには、TMSのCLIを実行して新しい文字列をプッシュし、オプションで翻訳された文字列をプルするステップが含まれます。これはスクリプトがビルドコンテキストへの完全なアクセスでCI環境で実行されるため、最も柔軟なパターンです。GitHub ActionsマーケットプレイスとGitLab CIには、主要なTMSプラットフォームのほとんどの公式またはコミュニティが維持するアクションが含まれています。トレードオフは、CLIバージョン、シークレットとしての認証資格情報、およびビルドステップに対するpush/pullステップの順序を管理する必要があることです。

ファイルウォッチャー。 ローカルデーモンが翻訳ファイルディレクトリを監視し、コードを書くときにリアルタイムでTMSに変更を同期します。これは主に開発者体験ツールです：翻訳者は、CIの実行を待つのではなく、開発者がそれらを追加してから数秒以内に新しい文字列を見ます。デーモンを実行している開発者に依存し、チーム全体で一貫したローカルセットアップが必要なため、本番パイプラインメカニズムとしては適していません。

OTA / CDN配信。 翻訳された文字列をリポジトリにコミットしてデプロイにバンドルするのではなく、アプリケーションは実行時にCDNまたはAPIから翻訳を取得します。翻訳の更新は、新しいビルドやデプロイなしにグローバルで即座に利用可能になります。このパターンは、ランタイム翻訳ローディング向けに設計されているアプリケーションを必要とします — これは最新のi18nライブラリのほとんどで標準的です — そしてCDNへのランタイム依存性を導入します。これはUIの文字列にとって最も運用上機敏なパターンです。

ほとんどの本番セットアップはパターンを組み合わせます：コードベースとTMSの同期を保つためのCIステップ（またはwebhook）、プラス新しいデプロイを必要としない文字列更新のためのCDN配信。

探すべき主要な機能

すべてのローカライゼーションプラットフォームが真の継続的ローカライゼーションをサポートするわけではありません。ツールを評価する際に、プラットフォームが手動の翻訳ポータルとして使用されるのではなく、実際にCI/CDパイプラインに統合できるかどうかを決定する機能があります。

新しいおよび変更された文字列の自動検出。 プラットフォームは、手動エクスポートを必要とせずに、ファイル差分またはVCSイベントから文字列の変更を自動的に識別する必要があります。変更のたびに完全ファイルをエクスポートして再インポートする必要があるプラットフォームは、継続的なワークフロー向けに設計されていません。

翻訳者のコンテキスト。 個々の文字列を孤立して作業する翻訳者は、UIのどこに文字列が表示されるかを見ることができる翻訳者よりも低品質の翻訳を生成します。最良のプラットフォームは、スクリーンショット、コンポーネントメタデータ、または実際のプロダクトにレンダリングされた文字列を表示するインコンテキスト編集を受け入れます。コンテキストなしでは、「保存」、「表示」、「キャンセル」などの短い文字列は、文脈から外れると意味が曖昧なため定期的に誤訳されます。

ブランチサポート。 チームがフィーチャーブランチを使用する場合、ローカライゼーションプラットフォームはVCSブランチを反映した翻訳ブランチをサポートする必要があります。フィーチャーブランチ上の文字列は、ブランチがmainにマージされる前に翻訳可能であるべきです — そうでなければ翻訳は常にコードより少なくとも1つのマージサイクル遅れます。

テスト用疑似ローカライゼーション。 疑似ローカライゼーションは、実際の翻訳なしに翻訳済みテキストをシミュレートするために、ソース文字列内の文字を視覚的に類似した拡張ラテン文字に置き換えます。これは、実際の翻訳が利用可能になる前の開発の早い段階でレイアウトバグ — テキストオーバーフロー、切り捨てられたラベル、ハードコードされた幅の仮定 — を発見します。自動疑似ロケール生成をサポートするプラットフォームにより、開発のどの時点でも任意のロケールでのUIテストが可能になります。

再デプロイなしのOver-the-air（OTA）アップデート。 翻訳を更新するために新しいビルドを出荷することが遅すぎるかコストがかかりすぎるアプリケーション — モバイルアプリ、デスクトップアプリケーション、または高頻度Webアプリ — にとって、OTA配信は不可欠です。プラットフォームは、低レイテンシでグローバルに分散したエッジキャッシュから翻訳を提供し、翻訳が公開されたときに自動キャッシュ無効化を行う必要があります。

翻訳メモリと一貫性の適用。 翻訳メモリはプロジェクトとコンテキストにわたって以前に翻訳された文字列を再利用し、翻訳者の労力を削減し、一貫性を向上させます。一貫性の適用は、以前に翻訳された用語と一致するが異なる方法で翻訳された文字列にフラグを立てます — 大規模なプロジェクト全体の用語のドリフトを発見します。

よくある落とし穴

継続的ローカライゼーションパイプラインは、手動ワークフローの問題とは異なる特定の障害モードを導入します。これらが最も一般的なものです。

QAレイヤーなしの過剰自動化。 完全に自動化された機械翻訳パイプラインは、高速で翻訳を出荷できます。また、高速で誤った翻訳を出荷することもできます。人間のレビューなしの機械翻訳は、内部ツールおよびリスクの低いUIの文字列には適切です。顧客向けのマーケティングコピー、法的開示、エラーメッセージ、またはブランドボイスを反映するものについては、人間のレビューステップはオプションではありません。MT翻訳はすぐにフォールバックとして公開され、人間がレビューした翻訳が非同期的にそれらを置き換えるようにパイプラインを設計します — 人間のレビューで公開をブロックしないでください、しかしすべてのコンテンツに対してMTを最終的なものとして扱わないでください。

翻訳者のコンテキストを無視すること。 コンテキストのハンドオフを自動化せずに文字列のハンドオフを自動化することは、低品質の翻訳を生成する高速なパイプラインを作ります。checkout.button.primaryのような文字列キーは、スクリーンショット、説明、または文字数制限なしに翻訳者にほとんど何も伝えません。最初からパイプラインにコンテキスト配信を組み込んでください — 後からレトロフィットする方がはるかに難しいです。

キーのリネームによる翻訳メモリの破壊。 翻訳メモリは、プラットフォームに応じて、翻訳をソース文字列またはキーにマップします。開発者がキーをリネームするとき — 例えば、user.save_buttonをprofile.save_changesに変更するとき — TMSは多くの場合これを削除されたキーと新しい未翻訳のキーとして扱います。その文字列のすべての以前の翻訳作業がTMから失われます。キーリネームポリシーを確立します：キーのリネームをdeprecated-and-create操作として扱う（翻訳が確認されるまで古いキーを保持する）か、キー名ではなくコンテンツハッシュを使用してキーの変更を通じて文字列のアイデンティティを追跡するTMSを使用するかのどちらかです。

削除されたキーの処理をしないこと。 文字列がソースから削除された場合、ほとんどのプラットフォームはそのTMS内の翻訳を無期限に残します。時間とともにこれは、ストレージを無駄にし、翻訳者を混乱させ、翻訳完全性のレポートを不正確にする孤立した翻訳を作ります。ソースに存在しなくなったキーの翻訳を削除する定期的なパージサイクルを実装します — CIスクリプトまたはTMSオートメーションルールを介して。

すべてのロケールを同じように扱うこと。 異なるロケールは、翻訳者の可用性、言語ペアの複雑さ、およびレビュー要件に応じて、異なる翻訳速度を持ちます。すべてのロケールが翻訳を完了することでデプロイをブロックするパイプラインは、最も遅いロケールによってしばしばブロックされます。準備ができている翻訳済みロケールでデプロイし、準備ができていないロケールにはソース言語にフォールバックするようにパイプラインを設計します — ロケールが定義した完全性のしきい値を下回ったときにアラートを出します。

継続的ローカライゼーションをサポートするツール

これらは、エンジニアリング主導の継続的ローカライゼーションパイプラインで最もよく使用されるツールです。それぞれに正直な強みと実際の制限があります。

Crowdin CLI。 CrowdinのコマンドラインクライアントはGitHub、GitLab、Bitbucketとネイティブ統合とwebhookサポートを通じて緊密に統合します。ブランチをサポートし、幅広いファイル形式ライブラリ（JSON、YAML、XLIFF、Android XML、iOS Strings、その他多数）を持ち、強力な翻訳メモリを提供します。CI統合は十分に文書化されています。制限：ブランチングモデルは複雑なモノレポに対して設定が混乱することがあり、OTA配信はより高いティアプランで利用可能なCrowdin OTA機能を必要とします。

Transifex。 TransifexはCLIとwebhookを介して長期的なCI/CD統合サポートを持っています。Webベースのリアルタイム翻訳のために「Live Translation」を導入しました — CDNから翻訳されたコンテンツでテキストノードをインターセプトして置き換えるJavaScriptスニペット。このアプローチはアプリケーションビルドプロセスへの変更なしに機能します。これはビルドパイプラインを簡単に変更できないチームにとって有用です。Liveアプローチはその動作がDOMレベルであるためパフォーマンストレードオフがあります。

Lokalise CI。 LokalisはGitHub ActionsとGitLab CIの強力な統合、翻訳レビューのための適切に設計されたコントリビューターワークフロー、およびiOS、Android、WebのSDKを介したOTAをサポートしています。そのブランチサポートはほとんどの競合他社よりも洗練されています。Webエディターはスクリーンショットベースのコンテキストサポートが優れています。Lokalisは一般的に中〜エンタープライズ市場を対象としており、それを反映した価格設定です。

Phrase CLI（旧Phrase Strings）。 Phrase（旧MemsourceおよびPhraseApp、現在は統一ブランド下）は包括的なCLI、強力なXLIFFサポート（XLIFFワークフローを好む専門翻訳代理店を持つチームに有用）、成熟した翻訳メモリおよび品質保証機能を持っています。専門翻訳代理店ワークフローで特に強いです。CI統合はしっかりしていますが、VCSネイティブオートメーションのためにCrowdinまたはLokalisよりも多くの設定が必要です。

Better i18n。 Better i18nは、CLI、React/Next.js/Vue/Svelte SDK、およびCloudflareのエッジネットワークを通じたCDNベースの配信を持つ開発者ファーストのアプローチを取ります。そのOTAモデルは、翻訳の更新が公開から数秒以内にグローバルで利用可能になることを意味します — 新しいビルドやデプロイをトリガーすることなく。AI支援の最初の下書き翻訳をサポートし、コードベースの近くで翻訳を管理したいエンジニアリングチーム向けです。CI統合はCLIを介して簡単です。2026年初頭時点では、CrowdinやLokalisやPhraseよりも初期段階であり、XLIFFワークフローやエンタープライズSSOなどの分野では機能セットが狭いです。

FAQ

Q: 翻訳者が技術的でない場合、継続的ローカライゼーションを使用できますか？

はい。パイプラインの自動化はエンジニアリング側にあります。翻訳者はTMSのWebインターフェースのみと対話し、そこでは翻訳エディター内の文字列を見ます — YAMLファイルやGitコマンドではありません。自動化はコードから文字列を抽出し、それらをTMSに送り、翻訳をマージして戻すことを処理します。翻訳者の体験は主にTMSエディターの品質と提供するコンテキストによって決まり、パイプラインのメカニクスによってではありません。

Q: まだマージされていないフィーチャーブランチをどのように処理しますか？

ほとんどのTMSプラットフォームはVCSブランチを反映した翻訳ブランチをサポートしています。ブランチマッピングを設定します — 例えば、feat/*に一致するフィーチャーブランチが対応するTMSブランチに同期します。翻訳者はマージ前にフィーチャーブランチ内の文字列を作業できます。ブランチがVCSでマージされると、TMSブランチもマージされ、翻訳が引き継がれます。これはブランチを明示的にサポートするTMSを必要とします — すべてがそうするわけではありません。

Q: 翻訳はリポジトリに存在すべきかTMSに存在すべきか？

理想的には両方です。リポジトリはソース文字列（開発者が書く文字列）の真実の源です。TMSは翻訳された文字列の真実の源です。パイプラインはそれらの間を同期します：ソース文字列はリポジトリからTMSに流れ、翻訳された文字列はTMSからリポジトリに戻る（またはCDNに）流れます。TMSなしにリポジトリのみに翻訳された文字列を格納することは、非開発者がコントリビュートするのを難しくします。リポジトリに同期せずにTMSのみに格納することは、ビルドを決定論的に再現するのを難しくします。

Q: ローカライゼーションパイプラインの健全性をどのように測定しますか？

これらの4つのメトリクスを追跡してください：翻訳カバレッジ（ロケールごとに翻訳を持つソース文字列の割合）、翻訳ラグ（文字列がソースに追加されてから最初の翻訳が公開されるまでの時間）、レビューバックログ（人間のレビューを待っている機械翻訳された文字列の数）、および孤立したキーの比率（ソースに存在しなくなったキーのTMS内の翻訳）。健全なパイプラインは高いカバレッジ、低いラグ、管理可能なレビューバックログ、およびほぼゼロの孤立したキーの比率を持っています。

Q: 小規模チームにとっての最小限の継続的ローカライゼーションセットアップは何ですか？

Webプロダクトを出荷する2〜5人のエンジニアのチームの場合：mainへのすべてのマージでTMSのCLIを実行して新しいソース文字列をプッシュする単一のCIステップ、最初の下書きに対して有効化された機械翻訳、および最も顧客向けの文字列に対する週次翻訳者レビューセッション。これだけでリリースをブロックするバッチ翻訳とほとんどのマージコンフリクトを排除します。OTA配信とブランチサポートは、プロダクトと翻訳者のワークフローが成熟するにつれて後から追加できます。

まとめ

継続的ローカライゼーションは、CI/CDの考え方をプロダクトの翻訳レイヤーへの論理的な拡張です。核心的な洞察は、翻訳はリリースのマイルストーンではなく、パイプラインのステージであるということです。文字列が通常の開発フローの一部として自動的に抽出され、翻訳者に渡され、レビューされ、マージされる場合、バッチワークフローでローカライゼーションを痛みを伴うものにするコスト — リリース遅延、陳腐化した翻訳、マージコンフリクト、開発者と翻訳者の摩擦 — はエンジニアリングの解決策を持つエンジニアリングの問題に還元されます。

この記事で説明されているパイプラインは仮説的ではありません。何十ものロケールに出荷している企業のチームが本番でその変形を実行しています。具体的な詳細は異なります — どのTMS、どのCIシステム、OTA配信がスコープに含まれるかどうか、どれだけの人間のレビューが必要か — しかし構造は一貫しています：機械的な作業を自動化し、人間の作業にコンテキストを提供し、翻訳の完全性を二進数のリリートゲートではなく継続的なメトリクスとして扱います。

チームにとって最も摩擦の少ない変更から始めてください：メインブランチのマージごとにTMSに新しい文字列をプッシュするCIステップ。そこから、ブランチサポート、コンテキスト配信、OTAアップデート、および自動品質チェックをインクリメンタルに追加します。各レイヤーは、完全なパイプラインの再構築を必要とせずに摩擦を減らし品質を向上させます。

目標は、開発者にとって見えないローカライゼーションワークフローです — 新しいロケールへの出荷がプロジェクトではなく、設定の変更であるような。

参考文献

[^1]: Martin Fowler, "Continuous Integration," martinfowler.com, https://martinfowler.com/articles/continuousIntegration.html

[^2]: W3C Internationalization Working Group, "Internationalization Best Practices for Spec Developers," W3C Working Group Note, https://www.w3.org/TR/international-specs/

[^3]: OASIS XLIFF Technical Committee, "XLIFF Version 2.1," OASIS Standard, https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

[^4]: GitHub Actions documentation, "Events that trigger workflows," https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

[^5]: GitLab CI/CD documentation, "GitLab CI/CD pipeline configuration reference," https://docs.gitlab.com/ee/ci/yaml/

[^6]: Unicode CLDR Project, "Unicode Common Locale Data Repository," https://cldr.unicode.org/

[^7]: IETF BCP 47, "Tags for Identifying Languages," https://www.rfc-editor.org/rfc/rfc5646

[^8]: Crowdin documentation, "CLI tool," https://developer.crowdin.com/cli-tool/

[^9]: Lokalise documentation, "CI/CD integrations," https://lokalise.com/blog/continuous-localization/

[^10]: Phrase documentation, "Phrase Strings CLI," https://support.phrase.com/hc/en-us/articles/5784095916188

最終更新：2026年3月