翻訳のプルリクエストはLovableのGitHub同期を壊す?

いいえ、翻訳のプルリクエストがLovableのGitHub同期を壊すことはありません。ただし、Lovableが同期している唯一のブランチにマージされることが条件です。Lovableは一度に1つのブランチだけを編集し、マージされたコミットをプロジェクトに取り込むため、翻訳のプルリクエストもそのブランチに届く1つのコミットにすぎません。globalize.nowはAIによるローカライゼーション基盤で、翻訳をリポジトリへのプルリクエストとして納品します。つまり、2つのシステムが接点を持つのは通常のGitマージの場面だけです。問題が起きるケースは限られており、ドキュメントにも記載されています。この記事ではそれらを順に見ていきます。

LovableのGitHub同期は実際どのように動くのですか?

双方向で、かつ単一ブランチです。Lovableのドキュメントによると、編集と同期の対象は一度に1つのブランチで、デフォルトではリポジトリのデフォルトブランチ(通常はmain)です。Lovableで行った変更はそのブランチにコミットされ、GitHub上でそのブランチにプッシュされたコミットはLovableに取り込まれます。

Lovableの外部からリポジトリに書き込む処理では、次の2点が重要です。

**取り込みはプッシュ通知に依存します。**LovableはGitHubからのプッシュ通知を受け取ってプロジェクトを更新します。同じドキュメントによると、この通知が届かなかった場合、そのプッシュに含まれるコミットはLovableに表示されません。ドキュメントに記載された対処法は、別のコミットをプッシュして新しい通知を発火させることです。翻訳のプルリクエストをマージしたのにエディタが英語のままなら、まずここを確認してください。

**同期対象のブランチは変更できます。**プロジェクトのGitHub設定にはブランチの切り替え機能があります。ここで作成したブランチは、mainからではなく、そのとき有効になっているブランチから分岐します。切り替えると、Lovableはそのブランチを編集・同期するようになります。その後にmainへマージした内容は、Lovableが使っているブランチにマージするまで、エディタには反映されません。

このセクションで1つだけ覚えるなら、翻訳のプルリクエストは、ブランチ切り替えに表示されているブランチにマージする必要があるということです。

GitHubがLovableのプッシュを拒否するとどうなりますか?

Lovableは変更を破棄せず、lovable-syncというブランチに退避させます。Lovableのドキュメントによると、これはコンフリクトやブランチ保護ルールのためにGitHubがプッシュを拒否した場合に起こります。その後、通常のレビュープロセスを経てlovable-syncを保護ブランチにマージします。

関連するセーフティネットもあります。Lovableが同期しているブランチをGitHub上で削除すると、Lovableはプロジェクトをlovable-fallbackという新しいブランチに切り替えます。また、リポジトリ自体を削除すると接続が切れて同期が止まりますが、リポジトリ名の変更では切れません。

これらは翻訳に限った話ではありません。Lovableの周りで2人目の書き込み手がどう振る舞うべきかという話で、翻訳のプルリクエストはその点で行儀のよい書き込み手です。レビュー可能なプルリクエストとして届き、保護ブランチに直接プッシュすることはありません。

翻訳のプルリクエストはどこに位置づけられますか?

Lovableのコミットと、あなたのマージボタンの間です。lovable-i18nスキルを導入済みで、Lovableのナレッジに置いた指示ルールで新しい文字列のラップを徹底しているLovableプロジェクトでは、流れは次のようになります。

1. Lovableが機能を実装し、新しい文字列をLinguiのマクロでラップして、同期対象のブランチにコミットします。
2. GitHubのワークフローがラップされた文字列をsrc/locales/配下のPOカタログに抽出し、その同期結果をコミットし直します。Lovableにはターミナルがないため、抽出はエディタ上ではなくGitHub上で実行する必要があります。
3. 変換は初回のみで、アプリ上で行います。リポジトリを接続すると、globalize.nowがコードベースを一度だけ変換し、カタログをプルリクエストとして納品します。それ以降は、プッシュジョブが新しいカタログユニットを翻訳し、翻訳済みのカタログもプルリクエストとして納品します。
4. プルリクエストを同期対象のブランチにマージします。Lovableがそのマージコミットを取り込み、アプリは新しい言語で表示されるようになります。

ないものに注目してください。Lovable側でのインポート作業も、Webダッシュボードからのエクスポートも、実行時に翻訳を読み込むウィジェットもありません。翻訳済みファイルはリポジトリ内のただのファイルです。この考え方はダッシュボードなしでLovableアプリをローカライズする方法の根拠にもなっています。具体的な接続手順はLovable連携ページをご覧ください。

Lovableと翻訳のプルリクエストは競合しますか?

はい、通常のGitの意味では競合し得ますが、プルリクエストを短期間で閉じていれば、まれにしか起こりません。競合が起きるのは、ブランチを切ってからマージするまでの間に、両方の書き込み手が同じファイルの同じ行を変更した場合だけです。

現実的に重なり得るのはPOカタログです。Lovableが文字列を追加すると、各src/locales/*/messages.poに訳文が空の新しいメッセージが追記されるため、アプリはソーステキストにフォールバックします。翻訳のプルリクエストが埋めるのは、プルリクエストを開いた時点でカタログにあったメッセージの訳文です。Lovableがファイル末尾に新しいメッセージを追記し、プルリクエストが同じファイルの前方のエントリを編集している場合、Gitは問題なく両方をマージします。同じエントリを両方が変更した場合は、コンフリクトマーカーが付きます。

次の3つの習慣で、この重なりが生じる期間を短く保てます。

**翻訳のプルリクエストは、開いたその日にマージする。**1週間放置している間にLovableが10個の機能をリリースする、といった状況にならない限り、競合が目立つことはありません。

**カタログエントリの参照コメントは手動で編集しない。**抽出ワークフローが#.と#:の行を再生成します。コンフリクトを解消するときは、訳文を含むエントリを残し、コメントは次回の抽出で書き換わるのに任せてください。

**マージ前に、古くなったブランチを最新に追従させる。**プルリクエストのブランチが遅れている場合は、先に更新します。

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Gitが指摘した箇所を解消してプッシュし、マージします。カタログはテキストで、各メッセージが1つのブロックになっているため、解消するコンフリクトはほとんどの場合ファイル全体ではなく1エントリで済みます。

ブランチ保護で何が変わりますか?

レビューが加わりますが、もともとレビューが前提の運用です。プルリクエストとして納品される翻訳は、ブランチに設定された必須チェックや承認をそのまま通ります。保護ブランチに拒否されたLovable自身のプッシュはlovable-syncに届くので、同じレビューを経てマージします。2つの経路は別々で、互いに妨げ合うことはありません。

デフォルトブランチを保護しつつLovableにも編集させる場合は、定期的にlovable-syncをマージすることになります。これはLovableのドキュメントに記載された仕様であり、翻訳の問題ではありません。気になる場合の選択肢は、Lovableのコミット作成者に対して保護ルールを緩めるか、プロジェクト設定で同期対象を専用ブランチに切り替えることです。どちらの場合も、翻訳のプルリクエストはLovableが同期しているブランチを対象にしてください。

ランタイム翻訳ウィジェットでは、なぜこの疑問が生じなかったのですか?

リポジトリに一切書き込まなかったからです。2026年8月31日にサービスを終了したLovalingoは、ブラウザ上でレンダリング済みのページを翻訳していたため、リポジトリにロケールファイルはなく、マージすべきプルリクエストもありませんでした。移行ガイドに沿ってコミット型のカタログへ移行したチームは、LovableのGitHub同期が複数の書き込み手を持つシステムであることに、初めて向き合うことになります。

これはトレードオフですが、妥当な選択です。翻訳テキストはレンダリング時に借りるものではなく、バージョン管理され、インデックス可能な自分たちの資産になります。その代わり、Lovableがどのブランチを使っているかは把握しておく必要があります。Lovableアプリの翻訳を保つもう一方の課題、つまりコードにカタログが追いつかない問題については、リリースのたびに翻訳が壊れる理由をご覧ください。アプリがデータベースにコンテンツを保存している場合、その層はリポジトリの外にあります。Lovableアプリでデータベースのコンテンツをローカライズする方法で解説しています。

書き込み元を1つのブランチにそろえる

プロジェクトのGitHub設定でブランチ切り替えを確認し、翻訳のプルリクエストをそのブランチにマージして、lovable-syncはエラーではなくやることリストとして扱いましょう。Lovableで開発していて、翻訳の運用を自分で抱えずに任せたい場合は、バイブコーダー向けページで全体像を、料金は専用ページでご確認いただけます。