コンテンツへスキップ

オプショナルな分析、セッション記録、広告は、同意しない限り無効です。これらを拒否してTransglotを利用できます。選択はいつでもCookieの設定で変更できます。 Cookieポリシー

毎日マージするチーム向け

継続的ローカリゼーション: すべての言語を、すべてのマージで。

継続的ローカリゼーションでは、コードの変更に伴って新しい文字列や変更された文字列を自動的に翻訳します。リリース前の別フェーズではなく、必要なコードと一緒にすべての言語が出荷準備完了の状態を保ちます。

これは2つの作業方法のシミュレーションであり、実測値ではありません。「変更をマージ」を押して右側の列をご覧ください。それが各言語のユーザーに見える内容です。
acme / web
mainAdd a gift cardcheckout.gift_card
frAjouter une carte cadeau翻訳済み
deGeschenkkarte hinzufügen翻訳済み
jaギフトカードを追加翻訳済み
arأضف بطاقة هدية翻訳済み
pt-BRAdicionar vale-presente翻訳済み
今すぐリリース可能な言語5件中5件
mainより遅れている文字列なし
簡潔な回答

継続的ローカリゼーションとは?

継続的ローカリゼーションは、新しい文字列や変更された文字列が発生した時点で自動的に翻訳に送られ、スケジュール調整なしで製品側に翻訳テキストが反映される作業方式です。

翻訳は止まらないため、専用の翻訳フェーズは存在しません。開発者が文字列をマージすると、コードと同じフローで翻訳も追随するため、リリースは誰かのファイルを待つ必要がありません。

これは継続的デリバリーのローカリゼーション版です。毎日マージしながら数週間ごとに翻訳を手渡すチームでは、毎月的大部分の期間で言語がコードに追いついていません。継続的ローカリゼーションなら、そのギャップを1回の実行時間分に縮小できます。

機械翻訳の出力を未確認で公開するという意味ではありません。人的レビューが必要な文字列を決定でき、リリースにはレビュー済みのもののみを含めることができます。

継続的 vs 従来のローカリゼーション

違いは翻訳のタイミングです。 担当者ではありません。

翻訳者、レビュアー、用語集は両方の方式に存在します。異なるのは、作業開始の時期と作業単位的大小です。
並列表示
翻訳の実施タイミング
各リリース前のフェーズで実施
開始のトリガー
担当者がファイルをエクスポート
作業単位の規模
数週間分の文字列を一度に処理
リリースが待つもの
ファイルの返却
直前の文案変更
往復の手間が再度発生
翻訳者の作業環境
文字列の一覧表(スプレッドシート)
ローンチ時の対応言語
段階的、波状展開
1つの文字列、開始から完了まで

継続的ローカリゼーションの仕組み

新しい文字列がループを通過する過程を追います。各ステップで実際に目にする内容を示します。

ターミナル、またはCIログ
+ "checkout.gift_card": "Add a {brand} gift card"
$ git push origin main
$ transglot push --wait
push locales/en.json (en, json_nested)
Batch: #4182
$ transglot pull
written locales/fr.json
written locales/ja.json
checkout.gift_card
ソースAdd a {brand} gift card
frAjouter une carte cadeau {brand}Glossa ドラフト
de{brand}-Geschenkkarte hinzufügenメモリから、0語
ja{brand} ギフトカードを追加Glossa ドラフト
arأضف بطاقة هدية {brand}Glossa ドラフト
4つのゲート、1回の実行
プレースホルダー1件修復済み
複数形合格
用語集の用語合格
所要時間合格
ja · プレースホルダー消失、1回修復、再チェック済みギフトカードを追加{brand} ギフトカードを追加
cart.save
ソース変更済みSave Save draft
frEnregistrer人によるレビュー:保持、あなたに報告提案: Enregistrer le brouillon
deEntwurf speichern機械翻訳行:再翻訳済み
プルリクエストその場で更新
翻訳を更新transglot/sync → mainオープン、リポジトリごとに1つ
locales/fr.json+3 −1
locales/de.json+3 −1
locales/ja.json+3 −1
または、GitHubのプルリクエストでコメント/translate

変更はCLI、GitHub Action、またはGitホスト上のアプリを通じてTransglotに届きます。ソースファイルは20種類のネイティブフォーマットのいずれかで解析され、各文字列はプロジェクトが既に保持している内容と比較されます。新規および変更された文字列のみが次の工程に進みます。

翻訳メモリからの完全一致は行に入力され、単語数は消費しません。残りは用語集、スタイルガイド、およびそのキーのコンテキストとともにGlossaに送られます。

プレースホルダー、複数形、用語集の用語、長さの制限が、各実行のすべての行でチェックされます。壊れたプレースホルダー、欠落した複数形、禁止された用語集の用語は一度修正されて再チェックされ、2回目の失敗でも修正されない場合は出荷されずに拒否されます。長さ制限のみ超過した行は書き込まれますが、Teamプラン以上の自動承認またはQA実行によりレビュー対象としてフラグが立てられます。

実行処理は、人が編集またはレビューした行を上書きしません。後でソースが変更された場合でも、そのテキストは保持され、実行処理はその行をカウントして通知します。Teamプラン以上では、承認待ちの提案アップデートが横に表示されます。

Gitアプリはロケールファイルを1つの同期ブランチにコミットし、プルリクエストを常に最新の状態に保ちます。GitHubでは、プルリクエストに /translate とコメントすると、ファイルがそのプルリクエスト専用のブランチに反映されます。またはCDNに公開すれば、リリース不要で実行中の製品が変更を読み取ります。

チームが苦戦するポイント

継続的ローカリゼーションが失敗する6つのパターンと、それぞれの防止策

実行処理が人の作業を上書きする

すべてのライターは、行の状態(実行処理、メモリ一致、プッシュ)を最初に確認します。人が編集またはレビューした行は保持され、実行処理によって報告されます。

fr、レビュー済み、ソースが直近で変更

保持、カウント、報告済み

壊れた文字列が本番環境に到達する

投入されたすべてのトークンは戻ってくる必要があります。ICUプロジェクトでは、レンダリング時にエラーとなるメッセージはプルリクエスト、コネクタ、CDNバンドルから除外され、実行処理によって特定されます。

{count, plural, one {# article}

ファイルから除外され、実行時に名前が指定される

リポジトリがボットによるプルリクエストで埋め尽くされる

リポジトリごとに1つの同期ブランチと1つのプルリクエスト。2回目のプルリクエストを開くのではなく、2回の迅速なプッシュがこれに収束します。

#812 #815 #819 #823 ローカライズ更新

#812 transglot/sync、その場で更新

ソースの編集により、古い翻訳が残ってしまう

各ターゲット行は、作成時のソースを記録するため、変更された文字列はすべての言語で同時に期限切れとして認識され、そのキーのみが再度実行されます。

「保存」が「下書き保存」に変更。fr、de、ja は依然として「保存」と表示

fr、de、ja でその1つのキーが再度実行

実行ごとにプロジェクト全体に対して再度課金される

実行規模は変更内容に基づいて決定されます。変更されていない文字列は送信されず、完全に一致するメモリ内の項目は単語数としてカウントされず、担当者がいる行は何も費やす前に拒否されます。

ファイルには48,000語が含まれています

今回の実行: 60語

未完成のプル操作により、ロケールファイルが消去される

サーバーがロケールのエントリなしを報告した場合、プル操作は内容のあるファイルの上書きを拒否し、パイプラインをそこで停止させるために終了コード1を返します。

プル: ja のエントリ0件、ファイルには1,204件あり

空のバンドルで locales/ja.json を上書きすることを拒否

  • run 4182 fr: ドラフトからプレースホルダーが欠落、再試行で修復
  • run 4182 de: 担当者があるため、3行を保持
  • run 4182 ja: メモリから41行、0語
  • run 4183 ar: 再試行後も複数形形式が欠落、行を拒否
  • pull locales/pt-BR.json に書き込み済み
  • sync transglot/sync が更新され、プルリクエスト #812
比較対象の2つに対して測定

3つすべてがあなたのリポジトリに接続されます。 異なるのは、マージ時に何が起こるかです。

2026年11月5日、各企業の自社ページから読み取り。価格欄は以下のリンク先にある比較ページから取得しており、プランと計算式を示しています。価格とプランは変更される可能性があるため、決定前にご確認ください。

Transglot
新しい文字列がマージされる
デフォルトで翻訳済み
プッシュにより実行が開始されます。プロジェクト設定でこれをオフにできます。
翻訳がチェックに失敗しました
1回修復を試行し、その後拒否します
すべての実行の各行において、壊れたプレースホルダー、複数形、または禁止用語を検出します。長さ超過も記録されます。ICUプロジェクトでは、壊れた行はプル、コネクタ、CDNから除外されます。
ユーザーが行を編集済みです
実行により書き込みが拒否されます
メモリマッチとプッシュも同様に行われます。後でソースが変更された場合、実行によりその行が報告されます。
活発なリポジトリでのプルリクエスト
1つのブランチ、1つのプルリクエスト
各プッシュ時にその場で更新されます。
プランのカウント対象
言語ごとに1回、翻訳された単語数
完全一致するメモリマッチは無料です。文字列の保存も無料です。
AIの利用料に含まれるもの
プランに含まれる単語数
別途請求されません。
同じ作業: 5,000 文字列を 10 言語に翻訳
$39/月
Team、翻訳込み
GitHub、GitLab、Bitbucket、Azure Repos、CLI、MCPサーバー
すべて対応
Git連携アプリはTeamプラン以上で、クラウド版に対応しています。
すでに使用しているツールを活用

文字列が存在する場所から開始できます。 どの経路でも同じパイプラインに到達します。

文字列がどの経路で入力されても、メモリ、用語集、ゲート、レビューは共通です。
.github/workflows/translations.yml
on:
push:
branches: [main]
jobs:
translations:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v7
- uses: transglot/transglot-action@v1
with:
token: ${{ secrets.TRANSGLOT_TOKEN }}
最初にやるべきこと

継続的ローカリゼーションの設定方法

  1. コードから文字列を抽出する

    ユーザーに表示されるすべての文字列は、ロケールファイル内で安定したキーを持つ必要があります。Transglotは20種類の形式に対応しているため、現在使用している形式をそのまま維持できます。

  2. リポジトリの接続

    initコマンドを実行すると、ロケールファイルが検出され、ブラウザ経由でサインインします。既存のファイルがアップロードされ、最初の翻訳が実行されます。

  3. マージごとに実行する

    GitHub Actionを追加するか、他のCIからCLIを呼び出し、あるいはGitHub、GitLab、Bitbucket、Azure Repos用のアプリをインストールしてください。

  4. 人の確認が必要な項目を決定する

    プルリクエストルールでmin_stateをreviewedに設定すると、そのファイルには人が確認済みの文字列のみが含まれます。設定しない場合、ドラフト状態のままリリースされます。

ご自身の数値で計算する

マージごとに実行した場合のコスト: 変更された単語のみ。

「単語」はソース言語の単語を指し、ターゲット言語ごとに1回カウントされます。実行規模は変更内容に基づいて決定されるため、プロジェクトの大小に関わらず、5つの言語で12の単語に変更があったマージでは60単語とカウントされます。

25
40
6
20,000
月間ワード数26,000これらの数値に基づく · 週25回のマージ、それぞれ40単語、6言語

Starterプラン対応:$19/mo、月間300,000単語まで。

これは上限の約9%です。

初回実行(1回のみ)120,000全言語における既存の文字列です。インポートした翻訳は再度翻訳されません。

これは翻訳のみを対象としたカウントです。品質チェック、ブランドボイスのドラフト作成、修正も単語数としてカウントされますが、メモリからの完全一致は無料です。CLIおよびGitHub ActionはStarterプランから、GitHub、GitLab、Bitbucket、Azure Repos用アプリはTeamプランから利用可能です。

対応できないこと

継続的ローカリゼーションでは解決できない3つの課題

コード内に埋め込まれたままの文字列

パイプラインは読み取れるものしか翻訳できません。ハードコードされた文字列や、部品を組み合わせて作成された文章は事前に修正する必要があり、これらがロールアウト停滞の主な原因となります。

文言の責任者が不在

自動化は文字列を移動しますが、製品内の用語の決定は行いません。用語集の所有者を明確にしないと、誰も読まない言語が気づかれないうちにずれていくことがあります。

判断が必要なコピー

法務関連のテキスト、価格設定、ブランドメッセージには人の目が必要です。レビューに回し、承認されるまで配信ファイルからは除外してください。

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

導入前にチームがよく抱く疑問。

継続的ローカライゼーションとは何ですか?
新規または変更された文字列が自動で翻訳に送られ、スケジュールされた受け渡しなしで製品に戻されるワークフローです。リリース前の翻訳フェーズを、変更ごとの小規模な実行に置き換えます。
従来のローカライゼーションでは、文字列をファイルにまとめてリリース近くに送信し、完了を待ちます。継続的ローカライゼーションでは変更が発生するたびに処理するため、作業単位が小さく、各言語を同時に公開でき、遅い段階でのコピー変更も、往復の手間ではなく単一キーの再実行で対応できます。
いいえ。CI/CD はコードのビルド、テスト、リリースを行います。継続的ローカライゼーションは、それと並行して翻訳を進めます。両者はパイプライン内で連携し、テストを実行するプッシュが翻訳用の文字列送信とファイルの取得も行います。
いいえ。GitHub、GitLab、Bitbucket、Azure Repos 用アプリは、パイプラインへの追加なしでプッシュに反応します。また、コンテンツコネクタは CMS やストアの変更を検知します。独自のワークフロー内で使用したい場合は、CLI や GitHub Action をご利用いただけます。
いいえ。下書きをそのまま公開することも、人がレビュー済みのもののみをプルルールで取り込むことも、ファイルごとに選択できます。レビュアーはエディター上で、用語集、メモリマッチ、スクリーンショットを行ごとに参照しながら作業します。
いいえ。実行、メモリマッチ、プッシュはいずれもまず行をチェックし、人が編集またはレビュー済みの行は保護されます。後でソースが変更された場合でも、そのテキストは保持され、実行時にその行がカウント・報告されます。Team プラン以上では、承認可能な提案アップデートが添付されます。
受け渡し作業を担当する専任者がいない小規模チームほど効果が大きくなります。1言語のみで出荷し、第2言語の予定がない場合は、導入を見送っても問題ありません。
実行は開始前にサイズが確定します。無料プランは硬い上限があります。有料プランは、従量制超過を有効にしない限り割り当て分で停止し、有効にした場合は設定した支出上限で停止します。CI では、制限を超えそうな場合に CLI がコード 3 で終了するため、パイプライン側で対応できます。
はい、GitLab.com、Bitbucket Cloud、Azure DevOps Services で利用可能です。セルフマネージド型 GitLab や Bitbucket Data Center はアプリ対象外ですが、Node 22 が搭載され API にアクセスできる任意の CI で CLI を実行できます。
はい。コンテンツコネクタは CMS、ストア、ヘルプセンターから読み取り、双方向対応のコネクタはレビュー済みの言語を書き戻します。インポート専用のものもあり、各コネクタのページで確認できます。
はい。ロケールを CDN に公開すると、製品はランタイム SDK を介して実行時にそれを読み取ります。最新 URL は 60 秒間キャッシュされ、公開されたバージョンごとに固有の URL が維持され、過去 20 バージョンが保持されます。
インポーターを使用すると、プロジェクト、キー、既存の翻訳を Lokalise, Phrase, Crowdin, Transifex, Weblate and POEditor から移行できます。インポートされた翻訳は人手による作業として扱われるため、実行によって上書きされることはありません。どのプランでも無料で、一度だけ実行できます。